Loading ToolBench
The server has clear, actionable tool names and generally descriptive parameter specifications using Zod schemas. All 7 tools follow verb_noun naming conventions (search_*, get_*) which is good. However, there are significant gaps: (1) output schemas are completely undocumented, responses are JSON.stringify'd without formal schema specs, forcing LLMs to guess return structure; (2) parameter descriptions exist but lack actionable constraints (no ranges, patterns, or format guidance); (3) error handling is minimal, errors return only error.message with no recovery guidance or categorization; (4) no tool annotations (readOnlyHint, etc.) despite all being read-only. The tools are simple and composable, but lack production-grade documentation depth. Naming is solid (search_movies, get_movie_details, search_person), avoiding ambiguous names. Parameter naming is consistent (movieId, tvShowId, query, language). But descriptions are brief and don't explain WHEN to use each tool vs. alternatives, and no parameter has format constraints despite accepting language codes and region codes.
Get detailed information about a specific movie by its ID
Get a list of trending movies
Get a list of trending TV shows
Get detailed information about a specific TV show by its ID
Search for movies on TMDB by title to get metadata like overview, release date, and rating
Search for people (actors, directors, etc.) on TMDB
No output schemas documented. All tools return JSON.stringify'd responses with no formal type definitions. LLMs cannot predict response structure, field names, or types. This violates pattern:tool and pattern:response-shaper.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 7 tools are read-only and could benefit from explicit readOnlyHint to guide agent safety reasoning. Missing per-tool metadata.
Parameter descriptions lack actionable constraints. 'language' param described as "Language code (e.g. 'en-US', 'zh-CN')" but no format pattern, length limits, or validation rules. 'region' similar. LLMs have no guidance on valid values and may hallucinate codes.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for TV shows on TMDB by title to get metadata like overview, first air date, and rating
Example values in parameter descriptions (e.g. 'e.g. en-US, zh-CN'). LLMs tend to reuse examples literally rather than adapting to actual user context. Should use format patterns instead.
Error handling is minimal. Catch blocks return only error.message with isError: true. No error categorization (retryable vs. user-fixable vs. fatal), no recovery guidance, no actionable next steps. Pattern:recovery-guide not followed.
Tool descriptions are brief (60-70 chars) and lack context. Missing: WHEN to use each tool vs. alternatives, prerequisite relationships (e.g., 'search_person may return multiple results, use get_person_details to fetch full bio'), and what downstream tools expect these results for.
No pagination support. search_* and get_trending_* tools may return large result sets. No limit, offset, page_size, or cursor parameters documented. Risk of context window exhaustion.