Skip to main content
Glama

upload_speech_audio

Uploads an authorized audio file from the configured upload root and registers it as an account-scoped speech asset, enforcing 50 MiB and 300-second limits for later speech workflows.

Instructions

Upload one externally authorized audio file from TOPMEDIAI_UPLOAD_ROOT using existing upload and STS registration APIs. Maximum 50 MiB and 300 seconds; local FFmpeg/FFprobe required. Existing upload URLs may be public. Returns a local account-scoped speech_asset_id. No synthesis or automatic retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new operational detail: 50 MiB / 300 s limits, a local FFmpeg/FFprobe dependency, and the privacy-relevant note that existing upload URLs may be public. It stops short of describing failure/error behavior or auth prerequisites.

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?

Four tight clauses, front-loaded with the action and its source constraint, then limits, dependencies, side effect, and exclusions. No filler sentences; each clause carries a distinct fact.

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 upload tool with no output schema, the description supplies the return value (a local account-scoped speech_asset_id), the size/duration bounds, and the non-synthesis scope. Only the file_path semantics and failure behavior remain thin.

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 0% and the single file_path parameter is undocumented in the schema. The description only indirectly informs it by stating files must live under TOPMEDIAI_UPLOAD_ROOT, giving the parameter a scoping constraint but no format, extension, or path syntax guidance.

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 verb (upload) and resource (one externally authorized audio file) with a clear scope qualifier (from TOPMEDIAI_UPLOAD_ROOT). The resource name cleanly separates it from upload_reference_image and upload_reference_media, 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 Guidelines3/5

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

It establishes the preconditions for use (external authorization, files sourced from TOPMEDIAI_UPLOAD_ROOT, FFmpeg/FFprobe installed) and excludes synthesis ('No synthesis or automatic retry'), but never states when to pick this over upload_reference_media or how it relates to generate_sts. Usage is implied rather than routed.

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