Every tool runs against the REST API as you. If a tool returns
less than you expect, check what a key can
see before assuming a bug.
Reading
list_automations
No parameters. Returns every automation in the catalog:id, name,
description, category, estimatedDuration in minutes, and an inputs array.
inputs is the schema for inputValues when you schedule. Each entry has an id
(the key to use), a type, a display name, sometimes options and a
defaultValue. Call this before scheduling anything — automation IDs and their
inputs are not guessable, and an assistant that invents them gets a 404.
list_scripts
No parameters. Returns your scripts with their IDs, names, descriptions and estimated durations. Scripts with an empty graph are omitted.The Script Builder is locked platform-wide, so most fleets have no scripts and
this returns an empty list. Automations are the thing to schedule.
list_devices
No parameters. Returns every phone you can reach — an owner sees the whole organization, anyone else sees phones assigned to them or carrying one of their tags — withid, name, model, OS, online, status, battery, slotState,
tags, and the accounts on the phone.
The id is what deviceId wants. slotState must be active for a run to be
accepted.
list_accounts
Returns the accounts you own, with username, platform, status, follower counts
and growth. The
username is the value an account_selection input wants — pass
it back exactly as returned. Usernames are stored lowercase and without a leading
@, whatever an assistant’s example shows.
list_schedules
Returns executions newest scheduled first. The device, script, account and
container references are expanded into objects in place;
automationId stays a
plain string. Each carries a status — pending, processing, completed,
failed, skipped or cancelled.
There is no offset, so limit is a cap and not a page. Raising it on a busy fleet
returns a lot of JSON; see limitations.
Scheduling
schedule_automation
schedule_script
Identical, withscriptId in place of automationId. A script’s inputValues
keys are node IDs from its graph, not friendly names.
Building inputValues
Use each input’sid as the key. The value’s shape depends on the input’s type:
The tool’s own description only teaches an assistant the first six types. If an
automation asks for
container_select or container_target, say so explicitly
in your prompt, or the assistant will guess.bulk_schedule_automations and bulk_schedule_scripts
Both take a singleexecutions array of 1 to 100 items. Each item carries its own
deviceId, scheduledAt, inputValues, enableAIRecovery and switchMobileData,
plus automationId or scriptId — so one call can put a different account and
different media on every phone.
Items are validated independently. The response reports created and failed,
with each failure naming its deviceId, an error and sometimes a code such as
MAX_REQUIRED or SLOT_EXPIRED. A call where every item failed is still a
success at the protocol level, so read the counts rather than trusting “done”.
What scheduling rejects
The codes are explained in Errors.
Media
upload_media
The server fetches the URL itself, so a signed link, a localhost address or
anything behind a login fails. The file name is taken from the URL. The response
includes the new content ID, which is what
push_media inputs want.
An upload that would exceed your organization’s storage allowance is rejected with
STORAGE_LIMIT_EXCEEDED. There is no way to file the upload into a collection
through this tool — see limitations.
list_media
Returns metadata only: ID, title, type, folder, size, dimensions, status, usage
count and dates. File and thumbnail URLs are stripped, so an assistant can list
your media but cannot look at it or link to it.