Skip to main content
Glama
Sign In
MCP Appium

MCP Appium

Official
by appium
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

appium_screen_recording

Start or stop mobile screen recording and save the session as an MP4 video. Use action=start to begin capture and action=stop to end and save the recording.

Instructions

Start or stop screen recording. action=start begins recording; action=stop stops and saves to MP4.

Input Schema

NameRequiredDescriptionDefault
actionYesstart begins recording; stop ends, retrieves, and saves it.
bitRateNoAndroid only. Video bit rate in bits per second.
videoFpsNoiOS only. Frames per second. Default: 10.
bugReportNoAndroid only. Display timestamp overlay. Requires API level 27+.
sessionIdNoSession ID; defaults to the active session.
timeLimitNoRecorder limit in seconds; it does not retrieve/save automatically, so call stop. iOS default 180/max 4200; Android default 180/max 1800.
videoSizeNoAndroid only. Frame size in WIDTHxHEIGHT format (e.g. 1280x720).
videoTypeNoiOS only. Video codec to use (e.g. libx264).
videoScaleNoiOS only. Width:height, each 1–16384 (e.g. 1280:720); one may be -1 or -2 to preserve aspect ratio.
pixelFormatNoiOS only. Output pixel format (e.g. yuv420p).
forceRestartNoRestart and discard any active recording; default false.
videoQualityNoiOS only. Video quality preset. Default: medium.
hardwareAccelerationNoiOS only. FFMPEG hardware acceleration backend.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.99.1
    • changedInput schema / properties / videoScale / pattern
      Previous value: -"^(?:[1-9]\\d{0,4}|-[12]):(?:[1-9]\\d{0,4}|-[12])(?![\\s\\S])"New value: +"^(?:[1-9]\\d{0,4}|-[12]):(?:[1-9]\\d{0,4}|-[12])$"
  2. Changed4 schema fields changedv1.95.0
    • changedInput schema / properties / sessionId / description
      Previous value: -"Session ID to target. If omitted, uses the active session."New value: +"Session ID; defaults to the active session."
    • removedInput schema / properties / videoFilters
      Removed value: -{
-  "description": "iOS only. FFMPEG video filters. Takes precedence over videoScale.",
-  "type": "string"
-}
    • changedInput schema / properties / videoScale / description
      Previous value: -"iOS only. Scaling value (e.g. 1280:720)."New value: +"iOS only. Width:height, each 1–16384 (e.g. 1280:720); one may be -1 or -2 to preserve aspect ratio."
    • addedInput schema / properties / videoScale / pattern
      Added value: +"^(?:[1-9]\\d{0,4}|-[12]):(?:[1-9]\\d{0,4}|-[12])(?![\\s\\S])"
  3. First observedv1.92.11

TDQS

B3.4/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, which is minimal context. The description adds that stop produces an MP4 file, but omits where that file lands, whether the path is returned, how forceRestart interacts with an in-flight recording, and that the recorder is stateful per session.

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?

Two short sentences with the core capability front-loaded and zero filler. Nothing is repeated or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stateful 13-parameter recorder with no output schema and thin annotations, the agent still lacks the outcome of the call — where the MP4 is saved or whether a path is returned — and any note that recording must be stopped explicitly. The description is far too thin for this tool's complexity.

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%, and the schema already documents action semantics, platform scoping, defaults, and the timeLimit caveat. The description's 'action=start/stop' restates what the schema already says, so baseline 3 applies with no added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair and resource ('Start or stop screen recording') and clarifies both action values, so an agent knows exactly what the tool does. It never contrasts itself with the nearby appium_screenshot sibling or other capture tools, so differentiation is left implicit.

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 start/stop pairing implies a workflow (begin capture, then terminate to persist), but there is no explicit guidance on when to choose recording over screenshot, when a session must already exist, or whether recording should be stopped before session teardown.

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

Deploy Server

Other Tools