Skip to main content
Glama

Stop async display recording

mobile_record_stop

Stops an active Android screen recording, saves the MP4 to artifacts, and returns its marks with offsets.

Instructions

Stop screenrecord with SIGINT, pull the MP4 into artifacts, and return marks with offsets.

Input Schema

NameRequiredDescriptionDefault
serialYesExact ADB serial from mobile_devices_list; never inferred when multiple devices exist
recordIdYes

Output Schema

NameRequiredDescriptionDefault
pathYes
marksYes
serialYes
recordIdYes
displayIdYes
sizeBytesYes
durationMsYes
artifactUriYes
startedAtIsoYes
stoppedAtIsoYes
physicalDisplayIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.5.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations declare the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false), so the description only needs to add context – and it does: it discloses the SIGINT termination mechanism, that the MP4 is copied into the artifacts store, and that marks with offsets are returned. It omits failure modes (unknown recordId, already-terminated session) and whether artifact retention is bounded.

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?

A single front-loaded sentence with three sequentially ordered clauses, each carrying information (mechanism, side effect, return). No padding, though it is terse enough that some behavioral context is squeezed out.

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?

An output schema exists, so the return value need not be explained in depth, and the description still flags that marks with offsets come back. For a two-parameter stop tool, the main remaining gap is the lifecycle linkage to mobile_record_start and error behavior, not the core call contract.

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

Parameters2/5

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

Schema coverage is only 50%: 'serial' is documented but 'recordId' has just a UUID format/pattern with no textual meaning. The description adds nothing about either parameter – it doesn't say where recordId comes from (presumably mobile_record_start) or why serial must be exact when multiple devices exist, which is the exact gap the low coverage leaves open.

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 (stop), the resource (screenrecord), and the concrete outcome (MP4 pulled into artifacts, marks with offsets). An agent can distinguish it from mobile_record_start and mobile_record_mark by name, though the description never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or prerequisite guidance. The pairing with mobile_record_start and mobile_record_mark is only inferable from the wording ('stop screenrecord', 'return marks'), and nothing states what to do if the recording was never started or already stopped.

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