Skip to main content
Glama
Sign In
Sync MCP Server

Sync MCP Server

Official
by synchronicity-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

check a speech preview

speech-previews_get
Read-only

Read a speech preview job's status to poll pending or processing work and retrieve its audio URL, duration, or failure error.

Instructions

Read the status of one speech preview job created by speech-previews_create. PENDING or PROCESSING means it is still running; SUCCESS fills the audio url and duration; FAILED usually fills error with a code and message, but error can be null, so check it before reading. jobs_get and jobs_wait do not cover speech previews, and this tool has no wait option: call it again while the job runs, and never create another preview to recover a running one. projectId is only an access check (pass the one used at create); the job is looked up by id within the session's organization, and an inaccessible project or an id not found there returns an error. Does not synthesize or bill.

Input Schema

NameRequiredDescriptionDefault
idYesSpeech preview id from speech-previews_create.
projectIdYesProject you passed to speech-previews_create, from projects_create or projects_list. It is read first to check access; an id you cannot access returns an error.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.4
    • changedInput schema / properties / projectId / description
      Previous value: -"Project the speech belongs to, from projects_create or projects_list."New value: +"Project you passed to speech-previews_create, from projects_create or projects_list. It is read first to check access; an id you cannot access returns an error."
  2. Changed2 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"Speech preview id from speech-previews_create."
    • addedInput schema / properties / projectId / description
      Added value: +"Project the speech belongs to, from projects_create or projects_list."
  3. Addedv0.1.5

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, the description discloses status semantics (PENDING/PROCESSING/SUCCESS/FAILED), which fields each terminal state fills, that error can be null and must be checked, that there is no wait option, that the job is looked up by id within the session's organization, and that the tool neither synthesizes nor bills. These are behaviors an agent cannot derive from structured fields.

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?

The description is front-loaded with the core action and status meanings, then the sibling-tool exclusions, then parameter semantics. Every sentence carries distinct information and there is no repetition of schema or annotation content.

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?

Although an output schema exists, the description still explains what status values imply and the null-error edge case. For a two-parameter, read-only polling tool with full schema coverage, nothing needed to call it correctly is missing.

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, but the description adds real meaning: projectId 'is only an access check (pass the one used at create)' and is read first to check access, while lookup is by id within the session's organization. That clarifies projectId's role far beyond the schema's wording.

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 description opens with a specific verb and resource: 'Read the status of one speech preview job created by speech-previews_create.' It immediately distinguishes this tool from the sibling create tool and from generic job tools later on, so an agent can identify the resource and its origin without opening the schema.

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?

It gives explicit routing guidance: 'jobs_get and jobs_wait do not cover speech previews,' there is no wait option, so 'call it again while the job runs,' and 'never create another preview to recover a running one.' It also states the access-check rule for projectId and the behavior on inaccessible project or missing id, covering when and when-not to use it.

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