Loading ToolBench
MCP server for Sveriges Radio's Open API - access Swedish radio programs, podcasts, live streams, schedules, news and traffic
The server defines 18 tools with consistent Swedish naming conventions and reasonable descriptions. However, there are significant gaps in parameter descriptions, inconsistent schema completeness, and missing output schema documentation. Most tools follow verb_noun patterns (list_*, get_*, search_*) which is positive. The Swedish-language descriptions are present but variable in quality and some lack actionable detail for LLM planning. Parameter validation appears robust via Zod schemas, but those schemas are not always visible in the provided code snippets, making verification difficult. Tool composition is good, each tool has a single responsibility. Error handling exists (SRAPIError pattern) but error recovery guidance in descriptions is minimal.
Se vad som sänds JUST NU på alla kanaler i Sveriges Radio.
Hämta musikhistorik/spellista för en kanal.
Visa vad som sänds JUST NU på Sveriges Radio. Kan visa en specifik kanal eller alla kanaler samtidigt med föregående, nuvarande och nästa program.
Kolla tablån för en specifik kanal med möjlighet att välja datum.
Hämta detaljerad information om ett specifikt avsnitt, inklusive ljudfiler för streaming och nedladdning.
Hämta komplett spellista för ett avsnitt med information om alla låtar.
Hämta senaste avsnittet för ett program.
Hämta senaste nyheterna från Ekot eller andra nyhetskanaler.
Majority of tools (14 of 18) have NO visible input schema in the provided source code. Only list_channels has a complete schema shown. This violates the critical requirement that every parameter must have type definitions. Per HARD SCORING RULES, tools without visible schemas must score 0 on schema dimension.
Tool descriptions vary widely in quality and actionability. Many are 50-60 characters (e.g., 'Hämta detaljerad information om ett specifikt radioprogram eller podcast'), at the low end of the 10-1024 character guidance. Descriptions lack explicit guidance on WHEN to use each tool vs similar alternatives. For example, search_programs vs get_program distinction is unclear, and search_episodes vs list_episodes is not explained.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 33 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | 2024-11-05+ | v1 |
Se vilken låt som spelas just nu på en musikkanal med artistinformation.
Hämta detaljerad information om ett specifikt radioprogram eller podcast.
Se när ett program sänds med information om sändningstider.
Hämta lista över trafikområden för att kunna filtrera trafikmeddelanden.
Se trafikstörningar, vägarbeten och andra trafikmeddelanden.
Lista alla radiokanaler från Sveriges Radio (P1, P2, P3, P4, lokala kanaler). Inkluderar live stream-länkar och kanalinformation.
Bläddra bland avsnitten för ett program med paginering och sortering.
Lista alla programkategorier från Sveriges Radio (Nyheter, Musik, Sport, Kultur, etc.).
Sök i avsnittstext och beskrivningar från Sveriges Radio.
Sök efter radioprogram och poddar från Sveriges Radio baserat på nyckelord, kategori, eller andra filter.
No visible output schema documentation for any tool except list_channels (which shows pagination). LLMs cannot plan downstream calls without knowing what fields will be returned. Tools should document: field names, types, and which fields are suitable for chaining to other tools (e.g., channelId for list_channels should appear in get_channel_schedule output).
Error handling in tool-utils.ts shows SRAPIError with code/message/details, but error messages are not recovery-focused. For example, when a program ID is invalid, the error should suggest 'Try search_programs() first to find valid program IDs' rather than just 'Invalid parameter'. The asJsonContent and formatErrorPayload helpers are present but descriptions lack 'what to do next' guidance that agents need.
Tool naming mixes concerns in a few cases. get_all_rightnow (tool #10) and get_channel_rightnow (tool #2) are confusingly similar, the distinction ('all channels' vs 'specific channel') is not obvious from names alone. A clearer pair would be 'get_rightnow_all_channels' and 'get_rightnow_channel'. Similarly, list_episodes and search_episodes both exist but their distinction is unclear without reading descriptions.
Parameter descriptions are not visible for tools 3-18 in the source. Only list_channels shows parameter metadata (channelId, channelType, audioQuality, pagination, page, size). Without parameter descriptions and type info for the other 14 tools, LLMs cannot determine valid input ranges, enums, or dependencies. This violates 'Every parameter needs a description' rule.