Skip to main content
Glama
veniceai

Venice MCP Server

Official
by veniceai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Venice ASR (Speech-to-Text)

venice_asr

Transcribe audio from a URL into paged text or timestamps, avoiding memory overload. Use a result handle to fetch later pages without re-charging.

Instructions

Transcribe audio. Fetches the URL server-side and forwards as multipart/form-data file upload. Upstream transcription JSON larger than 1 MiB is rejected so word/character timestamps cannot exhaust memory. Timestamp arrays and transcripts longer than 8000 characters are paged in the MCP result: such a transcription returns result_handle alongside the first page, and every later page must be requested with that handle so the clip is transcribed — and charged — exactly once. Handles are held in memory, per MCP session, for 10 minutes and only the 16 most recent survive, after which paging fails and a fresh transcription is needed. Supports x402 wallet auth (no Venice account needed) and API key.

Input Schema

NameRequiredDescriptionDefault
modelNo
languageNo
audio_urlNoAudio to transcribe. Required unless result_handle is supplied.
timestampsNoInclude word and character timestamps in JSON responses. Defaults to false.
text_offsetNoStart character of the transcript page (8000 characters each). Defaults to 0. Use result_handle with next_text_offset to read past the first page.
result_handleNoHandle returned by an earlier paged transcription. Pages that retained result without submitting another transcription, so audio_url is ignored when this is set. Expires after 10 minutes or once 16 newer results are retained; an expired handle is an error rather than a silent re-transcription.
response_formatNo
timestamp_limitNoMax entries returned per timestamp array. Defaults to 200. Follow next_timestamp_offset; it is null on the last page.
timestamp_offsetNoStart index into each timestamp array (word/segment/char). Defaults to 0. Use result_handle to move past the first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.3.0
    • addedInput schema / properties / audio_url / description
      Added value: +"Audio to transcribe. Required unless result_handle is supplied."
    • changedInput schema / properties / response_format / enum
      Previous value: -[
-  "json",
-  "text",
-  "srt",
-  "verbose_json",
-  "vtt"
-]New value: +[
+  "json",
+  "text"
+]
    • addedInput schema / properties / result_handle
      Added value: +{
+  "description": "Handle returned by an earlier paged transcription. Pages that retained result without submitting another transcription, so audio_url is ignored when this is set. Expires after 10 minutes or once 16 newer results are retained; an expired handle is an error rather than a silent re-transcription.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / text_offset
      Added value: +{
+  "description": "Start character of the transcript page (8000 characters each). Defaults to 0. Use result_handle with next_text_offset to read past the first page.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / timestamp_limit
      Added value: +{
+  "description": "Max entries returned per timestamp array. Defaults to 200. Follow next_timestamp_offset; it is null on the last page.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / timestamp_offset
      Added value: +{
+  "description": "Start index into each timestamp array (word/segment/char). Defaults to 0. Use result_handle to move past the first page.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / timestamps
      Added value: +{
+  "description": "Include word and character timestamps in JSON responses. Defaults to false.",
+  "type": "boolean"
+}
    • removedInput schema / required
      Removed value: -[
-  "audio_url"
-]
  2. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the 1 MiB upstream JSON cap, the exactly-once transcription/charging guarantee, per-MCP-session in-memory handles, the 10-minute TTL, the 16-result LRU eviction, that an expired handle errors rather than silently re-transcribing, and that both x402 wallet auth and API keys are accepted. This also explains why the annotations mark it non-read-only and non-idempotent.

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?

Front-loaded with the purpose, then ordered by importance (input handling, size limit, paging, handle lifetime, auth). The paging and handle-lifetime sentences are long and could be split, but for a tool with genuinely intricate stateful behavior almost every clause carries information an agent needs.

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?

No output schema exists, and the description compensates by explaining the paged result shape (result_handle plus next_timestamp_offset/next_text_offset on later pages). Model, language, and response_format semantics are left undocumented, which is the main remaining gap for a 9-parameter tool.

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?

With 67% schema coverage and 9 parameters, the description reinforces the relationship between audio_url, result_handle, text_offset/timestamp_offset and the paging fields, and adds the 8000-character page size that the schema only alludes to. model, language, and response_format receive no explanation in either place, so it is good but not exhaustive.

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 opening sentence gives a specific verb+resource ("Transcribe audio") and immediately scopes the input mechanism (server-side URL fetch forwarded as multipart/form-data). No sibling tool performs ASR – venice_tts, venice_voice_clone and venice_audio_quote are clearly distinct – so the purpose is unambiguous 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 Guidelines4/5

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

The description gives concrete usage conditions for the two invocation modes (audio_url for a fresh transcription, result_handle for subsequent pages) and states what happens when a handle is no longer valid. It does not name or exclude alternative tools, but no sibling overlaps this capability, so the context is clear.

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