Skip to main content
Glama

Get HLS segment or init file

immich_get_segment
Read-onlyIdempotent

Fetch an HLS init file or numbered media segment for a video asset using its id, session, and variant index, so clients can assemble or inspect stream chunks.

Instructions

Get HLS segment or init file

Streams an HLS init segment (init.mp4) or media segment (seg_N.m4s).

Immich operation: GET /assets/{id}/video/stream/{sessionId}/{variantIndex}/{filename} · tag: Assets

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesformat: uuid
keyNo
slugNo
filenameYespattern: ^(init\.mp4|seg_\d+\.m4s)$
sessionIdYesformat: uuid
variantIndexYes
x-immich-hls-msnNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it streams raw HLS artifacts and names the underlying endpoint, but says nothing about content type, range requests, or error behavior when a session expires.

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?

Three short lines with the purpose front-loaded and no filler. The endpoint/tag metadata line is compact and mildly useful, though it consumes space that could have carried usage guidance.

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

Completeness3/5

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

For a segment-streaming tool with no output schema and 43% param coverage, the description is minimally viable but leaves key operational questions open: how the session/variant are established and what the caller receives back. Annotations cover safety, but not the streaming contract.

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 coverage is only 43%, so the schema leaves gaps. The description partially compensates by spelling out the two valid filename forms (init.mp4, seg_N.m4s), but the semantics of sessionId, variantIndex, and the x-immich-hls-msn header remain undocumented in both places.

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 and resource ('Get' / 'HLS segment or init file') and clarifies the two artifact types (init.mp4 vs seg_N.m4s). It is distinguishable from the generic asset CRUD siblings, though it never names the closely related immich_play_asset_video or download tools it sits beside.

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 guidance on when an agent should fetch an HLS segment instead of using immich_play_asset_video, immich_view_asset, or immich_download_asset. Prerequisites (how to obtain a valid sessionId or variantIndex) are also absent, so usage must be inferred entirely.

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