Loading ToolBench
MCP server for uploading and managing videos on YouTube
The server defines 8 tools with consistent naming (verb_noun pattern) and basic schemas. However, significant gaps emerge: most tools lack structured output documentation, error handling guidance is minimal, and parameter validation is under-specified. Tool names follow action-verb conventions well (authenticate, accesstoken, channels, refreshtoken, upload_video, update_video, list_videos, check_job_status), which is a strength. However, descriptions are generic (many under 100 chars), parameter enums are missing (e.g., privacy_status and category_id accept free-form strings), and no output schemas are documented. The tools implement real functionality (OAuth, video upload, metadata update) but the schema definitions lack production-grade rigor. Composition is reasonable, related tools chain well (authenticate → accesstoken → channels → upload_video), but each tool would benefit from explicit output documentation and richer parameter constraints.
Exchange the authorization code for an access token and retrieve channel information
Generate the authorization URL for YouTube OAuth2 authentication
Retrieve all stored YouTube channels with their authentication tokens
Check the status of an asynchronous video upload or operation job
List videos from a YouTube channel with optional filtering and sorting
Refresh the access token for a specific channel
Update video metadata including publish schedule and made-for-kids status
No output schemas documented for any tool. LLMs cannot infer what fields to expect (e.g., does authenticate return a URL string or an object with url+state? does upload_video return a job_id or a full status object?). This violates pattern:tool-description and pattern:response-shaper.
Parameter enums are missing for constrained fields. privacy_status in upload_video and update_video accepts free-form strings instead of enums (private|unlisted|public). category_id is also free-form. This violates pattern:constrained-input and forces LLMs to hallucinate valid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Upload a video file to YouTube and store the job tracking information
Parameter descriptions lack validation rules. order_by in list_videos says 'Optional sort field (title, published_at, relevance)' but these appear to be examples, not enums. direction says 'asc or desc' but as free-form string, not constrained. The max parameter lacks min/max bounds (what happens if max=0 or max=999999?).
Descriptions are generic and under 100 characters for most tools. 'Retrieve all stored YouTube channels with their authentication tokens' (channels) and 'Refresh the access token for a specific channel' (refreshtoken) lack context on when/why to call them and what the agent should do with the results. Baseline for good descriptions: 50-200 chars with clear intent.
No error handling guidance documented. What does authenticate return if OAuth setup is missing? What if a video_path does not exist? What if a channel_id is invalid? Error responses should guide recovery: 'Channel not found. Try channels() first to list available channels.' Instead, the tool definitions assume errors are self-evident.
upload_video lacks confirmation/dry-run pattern. Uploading a video is an irreversible action. No indication that the tool supports preview, dry-run, or confirmation-before-execute to prevent accidental uploads of unintended content.
Parameter naming inconsistency and lack of human-friendly resolution. upload_video requires channel_id but channels returns Channel objects. No guidance on how to obtain or validate a channel_id from the channels output. If channels returns {id, name, custom_url}, agents may not know that 'id' is the channel_id to pass to upload_video.
list_videos pagination is documented but no indication of whether total count or next_cursor is returned. Agents cannot determine if all results have been fetched or if there are more pages. Baseline: paginated tools should return total_count or next_cursor.