Skip to main content
Glama

open_player

Read-onlyIdempotent

Open an inline Qencode video player in the chat for a playback URL.

Renders an interactive player (MCP Apps UI component) so the user can watch
a transcoded result without leaving the conversation. When a job in this
conversation is already Done with a playable URL, call this in the same
reply as `list_jobs` — do not only paste the link. Pass a playback URL from
`list_jobs` / `get_job_status_detailed`: a progressive file (`.mp4` /
`.webm`) or an HLS/DASH manifest (`.m3u8` / `.mpd`). QuickTime / `.mov`
and a presigned manifest succeed with `client_note` (Chromium cannot play
that container, and a signed playlist cannot load its segments). The card
shows that sentence. Some clients cannot play HLS/DASH in the widget: the
call succeeds the same way. Do not retry `open_player` on that URL and do
not transcode only to get a player.

A manifest MUST be a PUBLIC URL. A presigned one cannot play, because the
signature covers only the playlist while its segments are relative and
would 403 (the player would spin forever). A public Media Storage object
plays from `cdn_url` on `list_objects`. A private progressive file
(`.mp4` / `.webm`, no `cdn_url`) plays from `get_download_url` — pass that
URL here and do not append anything. A private HLS/DASH manifest cannot;
do not substitute a presign. Job temp-storage output URLs from `list_jobs`
stay valid for playback.

It resolves the per-user Qencode Player license key (a public client-side
site-key) via the portal bridge and hands it to the widget; the actual
playback happens client-side in a sandboxed iframe.

Args:
    source_url: https:// URL on the configured Qencode player allowlist —
        mp4, webm, or an HLS/DASH manifest. A presigned manifest URL is rejected.
        Pass a public manifest.
        `.mov` / QuickTime is rejected — submit `output: "mp4"` instead.
    poster_url: optional https:// image on the configured Qencode player
        allowlist, shown before playback starts.
    source_type: optional MIME hint, e.g. "video/mp4", "video/webm",
        "application/x-mpegURL" or "application/dash+xml". The player
        infers a sensible default when omitted.
    title: optional display title for the player.

The player accepts Qencode-hosted video and poster URLs: the fixed storage
and CDN hosts, plus public Media Storage hosts
`*.media-storage.us-west.qencode.com` and
`*.media-storage.eu-central.qencode.com` (`cdn_url` from `list_objects`).
Another host still returns a result, with no license key: `client_note`
says this chat can only play Qencode-hosted video, and the card shows
that sentence instead of a player. Do not transcode or upload the file
unless the user asks.
Follow `client_note` when it is set — do not improvise:
- Presigned manifest: re-open the player on the public URL of the same
  playlist (see above). Do not transcode to mp4 to dodge it.
- QuickTime / `.mov`: do NOT retry `open_player`. Tell the user in-chat
  playback needs MP4, then submit `output: "mp4"` (not `repack` +
  `container: "mov"`) and open the resulting `.mp4`.
- Unlisted origin: the result is the note above, not an error. Do not
  retry `open_player` on that URL. A public Media Storage object in
  us-west or eu-central uses `cdn_url`.

When the result carries a non-null `client_note`, pass its point on to the
user in the same reply. It describes how THIS client presents the player —
e.g. hosts that put the widget in a collapsed tool-call block, where the
user sees no video until they expand it.

Note: only public / temporary-storage outputs are supported for now.
Signed-cookie / DRM playback does not work inside the chat sandbox yet.

Input Schema

NameRequiredDescriptionDefault
titleNo
poster_urlNo
source_urlYes
source_typeNo

Output Schema

NameRequiredDescriptionDefault
titleNo
poster_urlNo
source_urlYes
client_noteNo
license_keyNo
source_typeNo
prefer_nested_embedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint/idempotentHint already covering the safety profile, the description still adds substantial behavioral context beyond annotations: license-key resolution via the portal bridge, sandboxed client-side iframe playback, host allowlist behavior, the client_note contract, and DRM/signed-cookie unsupported. Nothing here contradicts the readOnly/idempotent annotations.

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?

Front-loaded with purpose and the Args block, but it is heavily redundant: the presigned-manifest prohibition is explained in the body, again in Args, and again under client_note handling, and 'do not retry open_player' appears twice. The guidance is valuable but bloated, and a shorter form would preserve most of the value.

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

Completeness5/5

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

Given a mutation-free rendering tool with an output schema present, the description covers the edge cases an agent needs: public vs private progressive vs manifest sources, host allowlist failures returning client_note rather than errors, and the required in-chat surfacing of client_note. No operational gap remains.

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?

Schema description coverage is 0%, so the description carries the full burden — and it does: source_url format constraints (mp4/webm/m3u8/mpd, allowlist, presigned manifest rejected), poster_url semantics, source_type as an optional MIME hint with concrete examples and inference default, and title. All four parameters are given meaning the schema lacks.

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 first sentence states a specific verb+resource+mechanism: 'Open an inline Qencode video player in the chat for a playback URL.' It immediately distinguishes this rendering tool from data siblings like list_jobs, get_download_url, and transcode_video, and explains the MCP Apps UI nature of the result.

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

Usage Guidelines5/5

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

Explicit when-to-use ('When a job ... is already Done with a playable URL, call this in the same reply as list_jobs'), when-not-to-use ('Do not retry open_player on that URL', 'do not transcode only to get a player', 'Do not transcode or upload the file unless the user asks'), and named alternatives (list_jobs, get_job_status_detailed, list_objects, get_download_url). Routing is unambiguous.

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.