Loading ToolBench
Songsterr MCP demonstrates solid definition quality with well-structured tool naming (all verb-prefix action names), clear descriptions (123-178 chars, within the 10-1024 ideal range), and documented input/output schemas using Pydantic models. All 4 tools have explicit descriptions and input parameters with type annotations and field descriptions. Output schemas are modeled as typed Pydantic classes (TabResult, SearchTabsResponse, BestMatchResponse, GetTabResponse) with comprehensive field documentation. However, there are gaps: no enums/constraints on string parameters (e.g., 'pattern' and 'query' accept free-form strings without guidance on format or examples), limited parameter-level error guidance, and no documented idempotency or error classification patterns. Tool composition is sound, each tool has one clear responsibility and related tools can chain (search results return view_url and tab_id that feed into get_tab). No security issues detected (all tools are read-only, no credential parameters). The largest gap is error handling, tools call external APIs with retry logic but do not surface actionable error messages to the LLM (e.g., 'No results found for pattern. Try a broader search.' or 'Rate limited; retrying in 2 seconds.').
Get the single best matching tab for a search query (e.g. 'stairway to heaven led zeppelin').
Fetch a tab by Songsterr ID. Returns metadata and a working view_url to open the tab in a browser. Tab notation is not available via API — use view_url to view/play on Songsterr.
Get tabs by one or more artist names (comma-separated).
Search for guitar, bass, or drum tabs by keyword (song title, artist, or phrase).
String parameters lack constraint guidance. 'pattern' and 'query' accept free-form text with no minimum/maximum length, character restrictions, or format hints. LLMs may pass empty strings, extremely long strings, or special characters that fail or pollute the upstream API. Recommendation: Add length constraints (e.g., '1-200 characters'), allowed character ranges, and example patterns to parameter descriptions.
Error handling and recovery guidance missing. Tools have retry logic and semaphore control internally, but if a tool fails (network error, 404, 429), the response does not guide the LLM on what to do next. E.g., 'No tabs found for [pattern]. Try: (1) search with artist name only, (2) use a shorter keyword, or (3) search by song title instead of lyrics.' Currently, failures likely surface as opaque exceptions. Recommendation: Wrap tool calls with try-catch that translates API errors into structured recovery hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 81 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 65 | - | v1 |
No pagination parameters on search tools. search_tabs and search_by_artist do not expose limit/offset or return a next_cursor. If Songsterr returns >50 results, all are returned, potentially bloating the context window. LLM reasoning degrades with huge result sets. Recommendation: Add optional 'limit' (default 20, max 100) and 'offset' parameters; return result count and indicate if more results are available.
Missing idempotency/destructiveness documentation. While all tools are read-only (search/fetch), the tool descriptions and registry do not explicitly declare this via tool annotations (readOnlyHint). An LLM cannot programmatically distinguish between a read-only search and a state-modifying operation without consulting the description text. Recommendation: Add tool annotations (readOnlyHint=true for all 4 tools) if the MCP spec and fastmcp framework support them.