Skip to main content
Glama

speechify_get_job

Read a persistent upload job to retrieve aggregate result counts and one page of items, using a job ID with optional item cursor and limit.

Instructions

Read a persistent upload job, aggregate result counts, and one page of items.

Input Schema

NameRequiredDescriptionDefault
limitNo
job_idYes
item_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the full load, and it does disclose the return composition (counts plus one page of items) and that jobs are 'persistent'. It does not cover read-only safety explicitly, behavior on an invalid or expired job_id, rate limits, how pagination terminates, or what the counts represent.

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?

A single front-loaded sentence that names the action and the three returned components in order, with no filler. It is perhaps too terse given the documentation gaps elsewhere.

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?

With no output schema and zero schema-level parameter docs, the description should explain the item list shape, the count aggregates, and pagination behavior, but it only names them. For a three-parameter tool whose parameters are entirely undocumented, this leaves real gaps.

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%, with three parameters, and the description only vaguely gestures at 'one page of items', hinting at limit and item_cursor without explaining cursor semantics or the 500-item cap. It says nothing about job_id's format or where an agent obtains one.

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 gives a specific verb and resource ('Read a persistent upload job') and states what it returns ('aggregate result counts, and one page of items'), which distinguishes it from speechify_list_jobs and speechify_get_item. It stops short of explicitly naming those siblings.

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?

Nothing says when to call this rather than speechify_list_jobs (find a job id), speechify_list_items (enumerate all items), or speechify_session_status. An agent must infer that this is a single-job status-plus-page-of-results call.

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