Skip to main content
Glama
EmiyaKatuz

crispasr-agent-transcriber

by EmiyaKatuz

transcribe_video

Transcribe local video files offline using CrispASR. Extracts audio with ffmpeg and outputs text, SRT, VTT, or JSON for English and Chinese.

Instructions

Transcribe a local video file through a CrispASR server.

Extracts audio with ffmpeg before sending to CrispASR. Supports the same options as transcribe_audio.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNo
out_dirNooutputs
profileNoauto
file_pathYes
lid_modelNo
models_dirNomodels
server_urlNo
keep_serverNo
lid_backendNofirered
chinese_modelNo
english_modelNo
manage_serverNo
response_formatNoverbose_json
allow_model_auto_downloadNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are present, so the description must disclose behavior itself. It reveals that ffmpeg extracts audio before a CrispASR request, a useful non-obvious detail. However, it says nothing about output writing to out_dir, model downloading, server lifecycle management, or return formats, all of which are implied by the 14 parameters.

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?

Three short sentences, each adds value: purpose, pipeline, and option compatibility. No filler; key information is front-loaded.

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?

For a 14-parameter tool with no annotations and no output schema, this is incomplete. It explains the pipeline but omits side effects (files written, model downloads, server management) and return behavior; relying on a sibling tool for option details is an indirect substitute.

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?

With 0% schema description coverage and 14 parameters, the burden is on the description, but it names no parameter semantics. 'Supports the same options as transcribe_audio' is a useful pointer to a sibling tool, yet it does not explain model, out_dir, response_format, keep_server, or other options on its own.

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 opening sentence names a specific verb ('Transcribe'), a resource ('local video file'), and a target ('CrispASR server'). The ffmpeg extraction line explains the video-to-audio pipeline, and the last line ties it to transcribe_audio, making it clearly distinct from audio-only transcription.

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

Usage Guidelines4/5

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

The description clearly positions this tool for local video files, and the ffmpeg extraction implies video-to-audio handling. It does not explicitly list when-not-to-use cases or compare against sibling tools such as transcribe_audio or understand_video, so guidance stops short of a full routing rule.

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