Skip to main content
Glama

Change devices

AccountDevicesWriteTool
Destructive

Claim an unclaimed device, change a device's settings, flash its screen to identify it, mirror another device's sharable playlist onto it, or retry a stalled firmware update. clearDevicePlaylist is destructive; stopMirroringDevice is a DELETE but only clears the mirror link, not any data.

  • claimDevice: Claim an unclaimed device — params: friendly_id (body: The code shown on the device during setup)

  • updateDevice: Update a device — params: id (path), name (body), refresh_interval (body: Seconds between check-ins, 300 to 86400), orientation (body), sleep_mode_enabled (body), sleep_screen_enabled (body), sleep_start_time (body: Minutes after midnight, 0 to 1439), sleep_end_time (body: Minutes after midnight, 0 to 1439), sleep_until (body: Sleep once, from the next check-in until this ISO 8601 time (at most a year out); no offset means the account time zone, null cancels. Any later check-in, such as a button press, wakes the device), ota_enabled (body), low_battery_notification_enabled (body), low_battery_notification_email (body), low_battery_screen_disabled (body), percent_charged (body), visibility (body: one of standalone, sharable), model_id (body: listModels; a BYOD device can take any model), firmware_channel (body: one of development, test, staging, production), special_function (body), touchbar_mode (body: one of tap, swipe), temperature_profile (body: one of default, a, b), waits_for_next_render (body), refreshing_screen_disabled (body), maximum_compatibility (body), guest_mode_item_id (body), guest_mode_item_duration (body), palette_id (body: listPalettes), font_family (body), text_scale (body: one of small, regular, large, xlarge), theme (body), auto_advance (body: Beta: may change or go away. false keeps the current screen until a button press; taken only when management.writable_fields lists it), playlist_item_ttl (body: one of 24, 48, 72, 96, 120, 144, 168), custom_width (body: byod_custom model only), custom_height (body: byod_custom model only), custom_format (body: byod_custom model only), framework_size (body: one of sm, md, lg), maximum_image_bytes (body: byod_custom model only), dither_pixel_ratio (body: byod_custom model only), scale_factor (body: BYOD only), ui_scale (body: BYOD only), rotate (body)

  • identifyDevice: Identify a device — params: device_id (path)

  • clearDevicePlaylist: Clear a device playlist — params: device_id (path)

  • mirrorDevice: Point a device at another device's shared playlist — params: device_id (path), master_friendly_id (body: friendly_id of the sharable device to mirror)

  • stopMirroringDevice: Stop mirroring — params: device_id (path)

  • resyncDeviceMirror: Resync a mirrored device with its master — params: device_id (path)

  • retryDeviceFirmwareUpdate: Retry a stalled firmware update — params: device_id (path)

Input Schema

NameRequiredDescriptionDefault
actionYesThe API operation to run
paramsNoThe operation's path, query and body parameters by name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true for the whole tool, and the description adds genuinely useful nuance by narrowing that to specific actions ('clearDevicePlaylist is destructive') and clarifying that stopMirroringDevice removes only the mirror link, not data. That prevents an agent from treating every action as data-destroying. It still omits auth/permission requirements, reversibility of clearDevicePlaylist, and any rate-limit or failure behavior.

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?

The purpose sentence is front-loaded, followed by a scannable per-action bullet list matching the enum order, and the destructive caveats are surfaced immediately after the intro. It is long, but the length is justified by eight actions and ~35 nested parameters; a few body descriptions (e.g. sleep_until) are wordy though each detail is actionable.

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 needn't cover return values, and it does cover all eight actions plus their parameters and the key destructive semantics. Gaps are secondary: no mention of required permissions/scope, no error or partial-failure behavior, and no confirmation that unlisted device fields are left untouched by updateDevice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only exposes a generic 'params' object with no per-action structure, so the description carries the full burden and does so: every action's path/body params are listed by name with units, ranges (300-86400 seconds, 0-1439 minutes), enums (visibility, firmware_channel, touchbar_mode, text_scale, playlist_item_ttl, framework_size), and behavioral notes (sleep_until ISO 8601 semantics, auto_advance beta caveat tied to management.writable_fields). This is meaning far beyond anything the structured schema provides.

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 opening sentence states a concrete verb+resource scope ('Claim an unclaimed device, change a device's settings, flash its screen...') and the body enumerates all eight write actions with the exact operation names used in the enum. It clearly distinguishes itself from the sibling read tool AccountDevicesReadTool by being the mutation counterpart.

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?

Each action is annotated with its intent (claim vs update vs mirror vs resync vs retry), and the description explicitly warns that clearDevicePlaylist is destructive and that stopMirroringDevice is a DELETE that only clears the mirror link. It cross-references helper lookups (listModels, listPalettes) for enum values. It stops short of stating when to prefer this tool over AccountDevicesReadTool or excluding misuse cases.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources