Loading ToolBench
MCP server for Buzzsprout podcast management — episodes, audio upload, and publishing automation
Solid foundation with complete schemas and descriptions for all 6 tools. Tool names follow verb_noun convention (list, get, create, update, delete, upload). Descriptions are clear and action-oriented (avg ~150 chars, within 10-1024 baseline). All parameters have type definitions and descriptions. However, several patterns are missing: no output schemas documented, no error handling guidance, no pagination support for list_episodes, no idempotency hints for write operations, and no tool annotations (readOnlyHint/destructiveHint). Parameter descriptions lack format constraints (e.g., ISO 8601 format stated but not formalized). No recovery guidance in error scenarios.
Create a new Buzzsprout episode. Set published_at to a future ISO 8601 timestamp to schedule publication. Enable magic_mastering for server-side audio normalization.
Soft-delete a Buzzsprout episode by setting it to private. Buzzsprout API does not support permanent deletion. The episode is hidden from the public feed but can be restored by setting private to false via buzzsprout_update_episode.
Get details for a specific Buzzsprout episode including its public URL.
List all episodes for the configured Buzzsprout podcast.
Update an existing Buzzsprout episode's metadata. Only provided fields are changed.
Upload audio to a Buzzsprout episode. Provide audio_url for remote files (Buzzsprout fetches it) or audio_file_path for local files (uploaded via multipart). Optionally specify episode_id to add audio to an existing episode, or omit to create a new episode.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., episode_id from create_episode response). Clients must infer response structure from API docs.
list_episodes lacks pagination (limit, offset, page_size parameters and total_count in response). Large podcast feeds will blow context window. Baseline: 90% of A+ tools support pagination.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without reading descriptions. Agents need explicit risk classification.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
No error handling guidance. Errors from Buzzsprout API (auth failures, rate limits, invalid episode_id) are not caught or translated into actionable recovery steps. LLMs receive raw HTTP errors with no next-step guidance.
upload_audio parameter descriptions lack clarity on mutual exclusivity. 'audio_url' and 'audio_file_path' are mutually exclusive, but this is not stated. LLMs may pass both, causing ambiguous behavior.