Skip to main content
Glama

video_info

Retrieves size, frame rate, duration, frame count, codec, and audio presence for a workspace video, helping agents inspect media before editing or rendering.

Instructions

Size, fps, duration, frame count, codec and audio presence of a video in the workspace.

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about whether this is a read-only probe, what happens when the path is missing or points to a non-video, which container/codec formats are supported, or whether the file is decoded. Only the implicit word 'info' signals non-mutation.

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?

A single compact sentence with no filler, which is appropriate for a simple probe. However, it is a bare noun phrase rather than a front-loaded verb clause, so the reader has to infer that these fields are returned rather than configured.

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 one-parameter, no-output-schema tool, enumerating the returned fields does useful work that a schema would otherwise do. Still missing are path semantics, failure behavior, and any read-only assurance, which matter because nothing else in the definition supplies them.

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% for the single required 'path' parameter, so the description must compensate. The phrase 'in the workspace' hints that path is workspace-scoped rather than an arbitrary filesystem path, but format (relative vs absolute), accepted extensions, and resolution rules are left entirely undocumented.

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 enumerates the exact metadata returned (size, fps, duration, frame count, codec, audio presence) for a video resource, which is meaningfully more specific than the bare name 'video_info'. It lacks an explicit verb ('returns'/'inspects'), and it never distinguishes itself from the close sibling animation_info, which an agent could easily confuse with this 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as animation_info or import_video. An agent must infer that this is a pre-import/pre-render inspection step purely from the field list.

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