PostNitro

List Audio Files

postnitro_list_audio

Read-onlyIdempotent

List the audio files in your workspace, newest first. Call this to resolve the ID a video post's music needs in videoSettings.backgroundMusicId, or a scheduled reel in postSettings.backgroundMusicId (audioId, the older name, is still taken). Those fields take an ID, never a URL.

Audio is uploaded in the PostNitro app; this API lists and deletes but does not upload. An empty list means the workspace has no audio yet — ask the user to upload some in the app, and create the video without audio in the meantime.

When several files match what the user described, show the candidates (name, duration) and let them choose rather than guessing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "postnitro_list_audio"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Page number (default 1)
`limit`	No	Results per page (default 10, max 100)

Output Schema

Name	Required	Description	Default
`count`	Yes	Number of audio files on this page
`audios`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedOutput schema / properties / audios / items / properties / id / description

Previous value: -"Use as videoSettings.audioId / postSettings.audioId"New value: +"Use as videoSettings.backgroundMusicId / postSettings.backgroundMusicId"

First observedSep 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: ordering, the fact that audio cannot be uploaded through this API (only listed and deleted), and the meaning of an empty result with a fallback action. That is exactly the sort of behavior an agent cannot infer 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and ordering, then routing guidance, then edge cases — a sensible order with little waste. The parenthetical about 'audioId, the older name' is slightly dense and could slow an agent parsing the field names.

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?

An output schema exists, so return values need no explanation, and the description still covers the two behavioral edge cases an agent must handle: no audio in the workspace and multiple plausible matches. Nothing needed to call this correctly is missing.

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 description coverage is 100% and both parameters (page, limit) are documented with defaults and bounds, so the schema carries the load. The description adds nothing about pagination behavior, so the 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?

States a specific verb and resource ('List the audio files in your workspace') plus an explicit ordering ('newest first'). It is immediately distinguishable from postnitro_delete_audio and the other list_* siblings.

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?

Gives an explicit trigger (resolve the ID for videoSettings.backgroundMusicId / postSettings.backgroundMusicId) and a hard constraint ('those fields take an ID, never a URL'). It also covers the empty-list path and the ambiguous-match path, telling the agent to present candidates rather than guess.

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

All PostNitro tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?