Ravenpost

Search reel audio

list_audio

Read-onlyIdempotent

Search Instagram’s audio catalog for tracks that can be attached to a reel, then pass the chosen track’s id as create_post/update_post audio.audioId. Call it WITHOUT a query to get what is currently trending — that is the featured list. accountId must be an Instagram account connected through a Facebook Page ("FACEBOOK_LOGIN" in list_accounts); a directly-connected one cannot reach the catalog and gets an error saying so. Instagram connects directly today, so only an account connected through Facebook earlier can use this. Meta only exposes tracks licensed for third-party use, so this catalog is narrower than the one in the Instagram app — a track the user can pick on their phone may legitimately be missing here. The catalog is Meta’s, shared by every Instagram account — licensed tracks plus original sounds from other creators’ reels — not the user’s own data; searching it only reads and attaches nothing. This is Instagram-only. TikTok and Facebook expose no music API, so there is nothing to list for them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "accountId": "<accountId>"
    },
    "name": "list_audio"
  }
}

Input Schema

Name	Required	Description
`kind`	No	'music' = licensed catalog track (default); 'original_sound' = audio lifted from another creator's reel
`limit`	No	Max tracks to return (default 25)
`query`	No	Search text (song or artist). Omit to get trending tracks.
`accountId`	Yes	Instagram account id (from list_accounts) to search on behalf of

Output Schema

Name	Required	Description	Default
`tracks`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantive context beyond them: the catalog is Meta's shared licensed catalog rather than user data, it is narrower than the in-app catalog so missing tracks are expected, and a directly-connected account fails with a specific error. It stops short of covering pagination or result shape, but output schema exists so that is less critical.

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 purpose, then the required id hand-off, then usage rules — the ordering is sensible. It runs long at eight sentences and the closing 'This is Instagram-only' partially restates the earlier account/Instagram framing, but every remaining sentence carries distinct operational information.

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 4-parameter, open-world search tool with full annotation coverage and an output schema, the description covers the prerequisites, the trending fallback, the catalog's scope limits, and the platform exclusions. An agent has everything needed to decide to call it and to call it correctly.

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 100%, so the baseline is 3, but the description adds real meaning: omitting `query` yields the featured/trending list, and `accountId` carries a non-obvious constraint (must be FB-Page-connected, from list_accounts) that the schema does not state. `kind` and `limit` are left to the schema, which documents them adequately.

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: 'Search Instagram's audio catalog for tracks that can be attached to a reel', and immediately links to the sibling tools that consume the result (create_post/update_post `audio.audioId`). An agent can distinguish this from list_media, list_posts, or attach_media without opening a 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?

Gives explicit when-to-use (search by song/artist), when-not (omit query for the featured/trending list), the prerequisite (accountId must be a Facebook-Page-connected Instagram account, verifiable via list_accounts), and hard exclusions (Instagram-only; no music API for TikTok or Facebook). This is close to a complete routing spec.

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

All Ravenpost 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.