Skip to main content
Glama

get_job_status

Check the status of a transcribe or summarize job. Returns the current state and, when completed, an outputs array. Each output has either content (returned inline) or a presigned, time-limited (1 hour) download_url. Small text outputs (e.g. transcript SRT, clip-candidates, summary) come inline as content; larger outputs — transcript-words JSON for any non-trivial recording, plus video outputs like clip-video / clip-vertical-video — come as a download_url to fetch when needed. Optionally pass format (srt, txt, vtt, json, words, edit) to get the transcript content inline in the top-level transcript field — txt and vtt are derived from the stored SRT; json is v1 (segments only); words is v2 (segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json); edit is a plain-text "[NNNN] words..." paragraph list, one line per paragraph, for editing by hand — send the edited text to edit_from_transcript to cut a re-timed video from it. Poll this periodically after calling complete_upload — wait at least 60 seconds between checks. For files under 10 minutes, jobs usually complete within 1-2 minutes. For long files (1hr+), expect 10-30 minutes. Derivative jobs (extract_clip, extract_vertical_clip, publish_youtube, clips_vertical, clips_horizontal, edit_from_transcript) have no upload step and no awaiting_upload/awaiting_complete_upload states — a paid derivative job reports processing once its parent source is confirmed still in storage, or a terminal source_expired if the parent source has expired: stop polling, and re-run the parent job named in source_job_id to get a fresh source before retrying. publish_youtube is the one exception: its upload starts by itself as soon as payment settles, so a paid job goes straight to publishing. If it reports awaiting_trigger instead, the upload did not start — almost always because the YouTube account is not connected yet; connect it and the publish can be resumed. A completed publish_youtube job's outputs array carries a youtube_url-roled entry with a url field pointing straight at the published video, instead of a download_url.

Also use this to recover from lost state: if the original challenge was lost, call get_job_status(job_id) to retrieve a fresh challenge (status "awaiting_payment") or the upload URL (status "awaiting_upload").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoWhen the job is completed, return the transcript inline in this format instead of only a download URL. Options: "srt" (SubRip with timestamps), "txt" (plain text — no timestamps), "vtt" (WebVTT), "json" (v1, segments only), "words" (v2, segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json), "edit" (plain text, one "[NNNN] words..." line per paragraph — edit it and send it to edit_from_transcript to cut a re-timed video from it). Omit for download URLs only.
job_idYesThe job_id returned from a previous transcribe or summarize call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"When the job is completed, return the transcript inline in this format instead of only a download URL. Options: \"srt\" (SubRip with timestamps), \"txt\" (plain text — no timestamps), \"vtt\" (WebVTT), \"json\" (v1, segments only), \"words\" (v2, segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json). Omit for download URLs only."New value: +"When the job is completed, return the transcript inline in this format instead of only a download URL. Options: \"srt\" (SubRip with timestamps), \"txt\" (plain text — no timestamps), \"vtt\" (WebVTT), \"json\" (v1, segments only), \"words\" (v2, segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json), \"edit\" (plain text, one \"[NNNN] words...\" line per paragraph — edit it and send it to edit_from_transcript to cut a re-timed video from it). Omit for download URLs only."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "srt",
      -  "txt",
      -  "vtt",
      -  "json",
      -  "words"
      -]New value: +[
      +  "srt",
      +  "txt",
      +  "vtt",
      +  "json",
      +  "words",
      +  "edit"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"When the job is completed, return the transcript inline in this format instead of only a download URL. Options: \"srt\" (SubRip with timestamps), \"txt\" (plain text — no timestamps), \"vtt\" (WebVTT), \"json\" (structured segments with start/end times). Omit for download URLs only."New value: +"When the job is completed, return the transcript inline in this format instead of only a download URL. Options: \"srt\" (SubRip with timestamps), \"txt\" (plain text — no timestamps), \"vtt\" (WebVTT), \"json\" (v1, segments only), \"words\" (v2, segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json). Omit for download URLs only."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "srt",
      -  "txt",
      -  "vtt",
      -  "json"
      -]New value: +[
      +  "srt",
      +  "txt",
      +  "vtt",
      +  "json",
      +  "words"
      +]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses state values, the inline-vs-download_url output split, 1-hour URL expiry, expected completion times, derivative-job state exceptions, and the publish_youtube edge case. This is far richer than a generic status check.

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?

Long but dense and well front-loaded: the core status/output facts come first, followed by polling, derivative jobs, and recovery. Each paragraph has a distinct purpose with no filler, though it is somewhat wordier than necessary because it echoes format-enum details already present in the schema.

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

Completeness5/5

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

For a tool with no output schema, this description explains the output shape, role-keyed entries, state transitions, timing expectations, and failure recovery paths. An agent has everything it needs to call the tool correctly and interpret the result.

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 coverage is 100%, so the baseline is 3. The description adds real value by explaining that format returns transcript inline in a top-level field, describing derivation relationships (txt/vtt from SRT, json vs words), and noting job_id can recover a lost challenge or upload URL. It still partly repeats the schema's enum details, so it stops short of 5.

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?

Opens with a precise verb+resource: 'Check the status of a transcribe or summarize job', and immediately states what it returns (current state and outputs). It also explicitly covers derivative jobs and lost-state recovery, so an agent can distinguish it from siblings like complete_upload or clips_from_job.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: poll after complete_upload, wait at least 60 seconds, use it to recover lost state, and understand how derivative jobs differ. It names the triggering workflow and gives concrete timing expectations, leaving no ambiguity about how to apply the tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources