Skip to main content
Glama

AI SENSE Free Public Tools

Decode data from sound

decode_audio
Read-onlyIdempotent

Recover one checksum-verified AI SENSE audio message, the audio-v2 format or the earlier v1, from a PCM16 WAV recording at 44100 or 48000 Hz, mono or stereo, at most 40 seconds. Give storage_id for a WAV file of at most 4 MiB, uploaded through REST Storage first. WAV recordings exceed the inline MCP request limit. REST accepts files up to 8 MiB. Answers data_base64, byte_length and text when the recovered bytes are valid UTF-8. This is data-over-sound decoding, not speech transcription. Audio is processed by the API, and the decoded result is not stored. Stored input keeps its original lifetime. storage_id must name an ordinary 24-hour file, without a max_downloads limit. No API key, no account and no sign up.

Input Schema

NameRequiredDescriptionDefault
modeNoauto tries all three bands within one shared time limit, and the earlier v1 format only in audible. Pick audible, high or ultrasound when known.
storage_idYesA storage_id from store_file, from a previous tool result, or from REST /storage. Objects expire 24 hours after they were stored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / mode / description
      Previous value: -"auto tries all three bands within one shared time limit. Pick audible, high or ultrasound when known."New value: +"auto tries all three bands within one shared time limit, and the earlier v1 format only in audible. Pick audible, high or ultrasound when known."
  2. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"auto detects either tone range. Pick audible or ultrasound when known."New value: +"auto tries all three bands within one shared time limit. Pick audible, high or ultrasound when known."
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "auto",
      -  "audible",
      -  "ultrasound"
      -]New value: +[
      +  "auto",
      +  "audible",
      +  "high",
      +  "ultrasound"
      +]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that the API performs processing, the decoded result is not stored, the stored input retains its original 24-hour lifetime, no max_downloads limit is allowed on the storage object, and no API key or account is required. That is meaningful operational context an agent could not infer from the annotations.

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?

The core statement is front-loaded in the first sentence, with size, lifetime and auth details following in a logical order. A few clauses are peppered in as afterthoughts ("No API key, no account and no sign up" repeated in spirit by the earlier REST mention), which slightly dilutes density but does not obscure the call contract.

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?

There is no output schema, and the description compensates by naming the return fields (data_base64, byte_length, text) and the UTF-8 condition for text. Combined with the size, duration, sample-rate and storage-lifetime constraints, an agent has everything needed to call this correctly on the first attempt.

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 already 100% and the mode enum is documented in-schema, so the baseline is 3. The description adds real constraints on storage_id (must be an ordinary 24-hour file with no max_downloads limit, sourced from store_file or REST /storage) and reinforces the auto-vs-explicit band choice, pushing it above baseline.

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?

Opens with a specific verb and resource: "Recover one checksum-verified AI SENSE audio message... from a PCM16 WAV recording," and names the format variants (audio-v2 / v1). It also preempts confusion with a sibling capability by stating "This is data-over-sound decoding, not speech transcription," which sharply separates it from any transcription or generic read tool.

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?

Preconditions are concrete: 44100/48000 Hz, mono or stereo, at most 40 seconds, WAV of at most 4 MiB, and the file must be uploaded first through REST Storage because "WAV recordings exceed the inline MCP request limit." It doesn't explicitly route the agent to encode_audio for the inverse operation, so the alternative-tool mapping is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.