Skip to main content
Glama

read_cues

Retrieve subtitle cues from a file by cue number range or time window, with a configurable result limit and encoding override.

Instructions

Show cues, selected either by number or by time. Cue numbers are 1-based positions in the file (the same numbers every other tool uses).

Args: path: subtitle file. start_cue: first cue number (inclusive). Use with end_cue. end_cue: last cue number (inclusive). from_time: show cues that overlap [from_time, to_time). Format 00:01:02,500 or 62.5. to_time: end of the time window (default: end of file). limit: maximum cues to return (default 100, at most 500). encoding: force a text encoding.

Input Schema

NameRequiredDescriptionDefault
pathYes
limitNo
end_cueNo
to_timeNo
encodingNo
from_timeNo
start_cueNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses useful details such as the default limit of 100, maximum of 500, default to_time as end of file, and time-window overlap semantics. It does not explicitly state that the operation is read-only, how errors are handled, or how selectors interact if both cue numbers and time windows are supplied.

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?

The purpose is front-loaded in the first sentence, followed by a structured Args list. Every line adds useful information, and there is no redundant or filler wording.

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?

For a seven-parameter read tool with no annotations and an output schema, the description covers selection modes, parameter meanings, defaults, time format, and limit bounds. It is reasonably complete, though it could be stronger by explaining sibling-tool selection and the interaction between cue-number and time-window parameters.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does so for all seven parameters: path, cue ranges, time formats, overlap semantics, defaults, limit bounds, and encoding. The main remaining gap is that it does not specify precedence or interaction when both cue-number and time-window selectors are provided.

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?

The description uses a specific verb and resource: "Show cues", selected by number or time. It also clarifies that cue numbers are 1-based positions consistent with other tools. However, it does not explicitly distinguish this tool from the sibling search_subtitles tool.

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?

The description explains the two selection modes (by cue number or by time window), but gives no guidance on when to use read_cues rather than alternatives such as search_subtitles. There are no explicit exclusions or decision rules.

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