Search and discover currently playable Nordic cultural recordings.
Scored across 2 tools
The two tools have distinct intents: search_catalog is a broad discovery mechanism, while find_recording is a narrow, preference-based selector for a single playable item. There is mild overlap in that both search the same catalog, but the descriptions make the boundary clear.
Both tools follow a consistent verb_noun pattern: find_recording and search_catalog. The naming is predictable, readable, and matches the action each tool performs.
With only two tools, the server feels thin for a cultural catalog domain, though the pair covers both broad search and targeted recommendation. The count is borderline but not unreasonable for a narrowly scoped retrieval server.
The tools cover the core discovery workflow: searching the catalog broadly and finding a single matching recording. Minor gaps exist, such as no direct detail-retrieval or browse-by-category endpoint, but the provided surface is usable without critical dead ends.
Choose one currently playable recording in a requested cultural category and duration band, with optional format, language, subtitle and geography preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| category | Yes | ||
| duration | Yes | ||
| preferences | No |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| category | Yes | |
| duration | Yes | |
| nextSeed | Yes | |
| recording | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the behavioral trait that the tool selects a single 'currently playable' recording, which implies filtering for availability. However, it doesn't disclose details like whether the choice is random, deterministic, or how preferences affect selection. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and criteria. It is concise and readable, though it packs many preference dimensions into a long list, making it slightly dense. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested preferences object, an output schema, and 4 parameters with 0% schema coverage. The description gives a high-level overview but does not explain the seed parameter, the meaning of duration values, or how preferences interact. Given the output schema exists, return values are covered, but the selection behavior and seed semantics remain unclear, leaving an agent to infer important details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for parameter meaning. The description mentions 'cultural category', 'duration band', and optional 'format, language, subtitle and geography preferences', which maps to the category, duration, and preferences parameters. However, it does not explain the 'seed' parameter at all, and the mapping is somewhat loose (e.g., 'geography preferences' vs hideNorwayOnly). The description adds some meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Choose') and resource ('one currently playable recording'), and specifies the selection criteria (cultural category, duration band, optional preferences). It distinguishes itself from the sibling search_catalog by focusing on selecting a single playable recording rather than searching the catalog, though it doesn't explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when the agent needs to pick one playable recording matching criteria. It does not explicitly state when not to use it or mention the sibling search_catalog as an alternative, so the usage context is clear but lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Kulturbase for playable Nordic cultural programmes, recordings, works, series and people. Returns compact catalogue links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | A title, person, series or programme to search for. | |
| preferences | No |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's job is lighter. It adds useful context by specifying 'playable' content and the 'compact catalogue links' return shape, which are genuinely behavioral traits beyond the annotation. However, it doesn't disclose pagination, how many results are returned by default, or any limitations of the compact links, so it stops at an adequate but not rich level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the verb and resource front-loaded. Every clause earns its place and the scoping constraint ('playable', the object list) is stated before the return format. This is appropriately tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (nested preferences object with four un-documented sub-parameters, a limit field with no explanation). An output schema exists, so return details are less critical, but the parameter documentation gap and the lack of sibling differentiation mean an agent cannot confidently configure a correct call. The description is not complete enough for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'query' is described), and the description adds nothing about the 'limit' or the nested 'preferences' object. The preferences sub-fields (format, languages, hideNorwayOnly, requireSubtitles) are entirely undocumented in both schema and description. Since coverage is below 50%, the description needed to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), a clear resource (Kulturbase), and enumerates the object types covered (programmes, recordings, works, series, people). It also states the return format (compact catalogue links). It does not differentiate from the sibling find_recording, so an agent cannot tell when to prefer one over the other, keeping it one step below a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use search_catalog versus find_recording, no stated exclusions, and no hint of which scenario favors the sibling tool. The description only implies a broad search capability, leaving the agent to guess the intended call boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_recordingsearch_catalogFind Bizzy radio stations, read station cards and public author information. Read-only; no playback.
Public TV and radio catalogue with measured stream health, folders and M3U feeds for VLC.
Find concerts, theatre, sport and festivals in Sweden. Authless, read-only MCP.
Search events, conference weeks, cities, venues and artist schedules via remote MCP.
Add one secure layer between your agents and this server.