Sync MCP Server

Official

by synchronicity-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

check speech preview availability

speech-previews_get-options

Read-only

Check before creating a speech preview whether it fits the free monthly TTS allowance or draws on paid usage, and flag billing or plan issues to resolve in Studio.

Instructions

Preflight one speech preview before speech-previews_create: confirm you can read projectId, then read the organization's text-to-speech billing state. It returns no price, so use it to tell the user before creating whether the preview fits the free monthly allowance (freeMonthlyLimits.tts used against max, when freeMonthlyLimits is not null) or will draw on paid usage, judged from hasActiveCredits, plan and billingVersion. If freeTtsExhausted or paymentFailureCountExceededLimit is true, tell the user to check their plan or billing in Studio instead of creating. Ignore freeGenerationsExhausted and the generations and sync3 counters; they cover other generations, not speech. available is always true when the call succeeds; if the project check or billing read fails, the call returns an error and no billing fields. Not for overall balance or spend (account_get-usage) or choosing a voice (voices_list). Does not synthesize or bill.

Input Schema

Name	Required	Description	Default
`projectId`	Yes	Project the speech preview is for, from projects_create or projects_list. Use the same id for speech-previews_create; an id you cannot access returns an error.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.4Nov 7, 2026

changedInput schema / properties / projectId / description

Previous value: -"Project the speech belongs to, from projects_create or projects_list."New value: +"Project the speech preview is for, from projects_create or projects_list. Use the same id for speech-previews_create; an id you cannot access returns an error."

Changed1 schema field changedNov 6, 2026
- addedInput schema / properties / projectId / description
```
Added value: +"Project the speech belongs to, from projects_create or projects_list."
```
Addedv0.1.5Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real substance beyond them: no price is returned, available is always true on success, a failed project check or billing read yields an error with no billing fields, and it neither synthesizes nor bills. The only mild gap is that it does not say whether the billing read is eventually consistent or rate-limited, so 4 rather than 5.

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?

Purpose and preflight timing are front-loaded, and the negation list of ignored counters (freeGenerationsExhausted, generations, sync3) is genuinely load-bearing because it prevents a wrong conclusion from the payload. Sentences are long and comma-heavy, which slightly hurts scannability, keeping it from a 5.

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 one-parameter preflight with an output schema, the description supplies everything an agent needs: when to call, how to interpret freeMonthlyLimits.tts against max when non-null, which flags should block creation, which counters to ignore, and how failures manifest. Nothing material is left to inference.

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?

Schema coverage is 100% and the single projectId parameter is fully documented there, including the UUID format and the "same id as speech-previews_create" guidance. The description only echoes the access-check semantics of projectId, adding marginal meaning beyond the schema, so baseline 3 applies.

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 first clause names a specific verb and resource ("Preflight one speech preview") and immediately positions it relative to the sibling speech-previews_create. An agent can distinguish this read-only preflight from the actual create call without opening either 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 states the trigger (before speech-previews_create), the decision the caller should make with the result (tell the user whether the preview fits the free monthly allowance or draws on paid usage), and explicit exclusions with named alternatives: account_get-usage for balance/spend and voices_list for voice selection.

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

Deploy Server