GimmeText

Get job status

get_job

Read-only

Use to check whether a transcription is finished. Poll every ~10 seconds until status is done or failed.

Input Schema

Name	Required	Description	Default
`id`	Yes	Job id (UUID).

Output Schema

Name	Required	Description
`id`	Yes	Job id (UUID).
`error`	No	Failure message when status is failed, otherwise null.
`status`	Yes	queued, running, done or failed (more values may be added).
`progress`	Yes	Progress from 0 to 100.
`upgrade_url`	No	Present when the user is nearly or fully out of minutes: where to add hours or upgrade.
`duration_seconds`	No	Audio length in seconds, or null until known.
`remaining_seconds`	No	Seconds of transcription the user has left (monthly minutes plus any hour pack).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

addedOutput schema / properties / remaining_seconds

Added value: +{
+  "description": "Seconds of transcription the user has left (monthly minutes plus any hour pack).",
+  "type": "number"
+}

addedOutput schema / properties / upgrade_url

Added value: +{
+  "description": "Present when the user is nearly or fully out of minutes: where to add hours or upgrade.",
+  "type": "string"
+}

Changed1 schema field changedOct 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "duration_seconds": {
+      "description": "Audio length in seconds, or null until known.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Failure message when status is failed, otherwise null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "id": {
+      "description": "Job id (UUID).",
+      "type": "string"
+    },
+    "progress": {
+      "description": "Progress from 0 to 100.",
+      "type": "number"
+    },
+    "status": {
+      "description": "queued, running, done or failed (more values may be added).",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "progress"
+  ],
+  "type": "object"
+}

First observedOct 11, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the valuable behavioral detail that this is a polled, non-terminal operation with two terminal states (done/failed). It does not describe the returned status values, but an output schema exists to cover that.

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?

Two sentences, zero filler, with the purpose front-loaded and the polling instruction second. Every clause earns its place.

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 one-parameter read tool with full annotation coverage and an output schema, the description supplies exactly the missing piece: the polling contract and termination condition. Only a pointer to what to do after completion would add more.

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?

With a single required parameter at 100% schema description coverage ('Job id (UUID)'), the schema carries the semantics fully. The description adds nothing about the id, so the baseline 3 applies.

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?

States a specific action (check whether a transcription is finished) which clearly identifies this as a status-polling tool for a job. It implicitly separates from get_transcript (content retrieval) and list_jobs (enumeration), though it never names those siblings explicitly.

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?

Gives concrete operational guidance: poll every ~10 seconds and stop when status is done or failed. It does not say what to do once done (i.e., call get_transcript) or what to do on failure, so the routing to alternatives is left implied.

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

All GimmeText tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?