radiobrowser-api-mcp

by maxim75

Overview Schema Source Related Servers Discussions Admin

Python

Remote

list_codecs

Get available internet radio stream codecs with station counts. Use an optional filter to narrow results.

Instructions

Stream codecs with station counts (GET /json/codecs[/{filter}]).

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": "list_codecs"
  }
}

Input Schema

Name	Required	Description	Default
`filter`	No
`timeout`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 6, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that this is a GET (read) operation and that the response includes station counts, which is useful. However, it does not mention behavior such as pagination, error cases, rate limits, or the exact effect of the filter beyond being part of the URL path.

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?

The entire description is one compact sentence that leads with the primary action, follows with the key output detail (station counts), and ends with the endpoint syntax. No redundant words or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers the core purpose and endpoint. However, it leaves the timeout parameter and usage guidance unaddressed, and without annotations it does not fully stand alone as a complete specification.

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 0%, so the description must compensate. It adds meaningful semantics for the 'filter' parameter by showing it appears as a path segment in the endpoint. However, the 'timeout' parameter is not mentioned at all, leaving its units and behavior unspecified.

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 description states a specific verb ('Stream'), the resource ('codecs'), and the unique output ('with station counts'). It includes the endpoint path, which further clarifies the action. Among sibling tools, this is the only one targeting codecs as the primary resource, so it is clearly distinguishable.

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?

The description implies the tool is used when you need a list of codecs with station counts, and the endpoint hints at optional filtering. However, it provides no explicit guidance on when to choose this over related siblings like find_stations_by_codec, nor does it mention any exclusions or alternatives.

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