Skip to main content
Glama
Galbaz1

video-research-mcp

by Galbaz1

Media Caption Events

media_caption_events

Generate time-stamped captions for audio, visual, and combined events in a local media file, validating the source hash and preparing a dry run before submission.

Instructions

Caption timed audio, visual and combined occurrences with submitted support.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYesExact local AV selection and source-supported event captions; dry preparation by default

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.1

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already signal non-read-only, open-world, non-idempotent, non-destructive behavior. The description adds only the vague phrase 'with submitted support' and does not disclose the dry_run default (true), the authorize_submission gate, or that a local file with a verified hash is required. For a submission-oriented tool these are material omissions.

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?

It is a single front-loaded sentence with no redundancy, but the phrasing is vague filler ('with submitted support') rather than information-dense, so brevity comes at the cost of substance.

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?

This is a complex tool with a nested request object, many defaulted limits, an authorization flag, and hash verification, plus an output schema. The one-line description omits the dry-run default, the submission authorization requirement, and the local-source constraint, leaving the agent under-informed about how to invoke it safely.

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 description coverage is 100%, so the nested request object, limits, dry_run, and sha256 pattern are already documented structurally. The description contributes no additional parameter meaning, which is the baseline-3 case when the schema does the heavy lifting.

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

Purpose3/5

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

The verb 'caption' and the objects 'timed audio, visual and combined occurrences' give a rough sense that this generates event captions over media, but the trailing phrase 'with submitted support' is cryptic and no sibling (media_count_events, media_ground_events, media_perceive) is distinguished. An agent can guess the domain but not the precise operation.

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 mention of prerequisites (local file, sha256), and no routing to or away from the closely related event tools. The agent must infer usage entirely from the schema.

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