Skip to main content
Glama

control_owned_video

Inspect and control owned course videos: start muted playback at a chosen rate, minimize or bring the player forward, and track local viewing without seeking.

Instructions

Inspect media; play initializes muted UI, applies inspected 1.25 adapter, minimizes and watches locally. Never seek. Use rate=1 for normal speed.

Input Schema

NameRequiredDescriptionDefault
rateNo
actionNoinspect
minimizeNo
bring_to_frontNo
allow_completed_replayNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.4

TDQS

C2.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full behavioral burden. It hints at muted UI on play, local watching, and a no-seek restriction, but omits state changes, permissions, and the effects of the minimize/bring_to_front flags, and the jargon obscures rather than clarifies behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short (two sentences) with no obvious filler, but it is dense with unexplained jargon and front-loads a vague verb. Brevity is achieved at the cost of clarity.

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?

With 5 undocumented parameters, 0% schema coverage, and no annotations, the description leaves most invocation details unexplained. The output schema covers return values, but the input side remains inadequate for correct use.

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 description coverage is 0% across 5 parameters, so the description must compensate. It only touches rate ("rate=1 for normal speed") and loosely implies action/minimize; bring_to_front and allow_completed_replay are entirely undocumented, and the action enum is never revealed.

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

Purpose2/5

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

The description opens with "Inspect media" but then drifts into jargon like "applies inspected 1.25 adapter," which does not clearly state what the tool does. It never defines the tool as a video-playback controller nor distinguishes it from siblings such as set_owned_video_rate or monitor_owned_video.

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?

It gives constraints ("Never seek", "Use rate=1 for normal speed") but no guidance on when to use this tool versus alternatives. With siblings like set_owned_video_rate and monitor_owned_video present, the absence of routing guidance is a real gap.

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