Loading ToolBench
Read-only MCP server for shakespeare-monologues.org — search and fetch Shakespeare monologue metadata over the Model Context Protocol.
The server demonstrates solid definition quality with clear tool naming, comprehensive parameter schemas using Zod, and descriptive docstrings. All 5 tools follow verb-noun naming conventions (search_*, get_*, random_*, list_*). Parameter descriptions are specific and well-written (averaging 80+ chars). Input schemas are properly typed with enums, constraints, and validation. However, output schemas are not explicitly documented, responses are returned as JSON without a formal schema definition. Error handling provides actionable guidance (e.g., NO_ID_MSG with next-step instructions). The tools are read-only with no destructive operations, reducing risk. Minor gaps: output structure not formally documented in code; some edge cases (e.g., upstream API failures) could have richer recovery guidance.
Fetch one monologue's catalogue entry by its numeric id. Follow the returned `url` for the full text.
List every monologue spoken by a given character (e.g. 'Hamlet', 'Rosalind'). Matches the character name exactly first, then as a substring.
List Shakespeare's plays with their classification (Comedy/History/Tragedy) and monologue counts.
Return one random monologue, with optional gender/play filters. Useful for a suggestion when the user is undecided.
Search Shakespeare monologues by free text (matches character, play, or first line) plus optional filters. Returns matches, each with a permalink `url`.
Output schemas not formally documented. While tools return structured JSON, the response structure is not declared in tool definitions. LLMs cannot plan downstream operations or know what fields to expect without explicit output schema documentation.
Tool name 'list_all_monologues_for_a_character' is unnecessarily long and includes redundant 'all' (27 chars vs 18-char median). Simpler name like 'list_character_monologues' would be clearer and faster for LLMs to parse.
Error recovery guidance for upstream API failures is minimal. If the upstream API at shakespeare-monologues.org is down, the tool throws a generic error without suggesting timeouts, fallbacks, or retry strategies. Error messages should guide the LLM through recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
No rate limiting or concurrent request protection documented. With caching at 1 hour TTL, a misbehaving agent could hammer the upstream API during cache misses. Add per-agent rate limits or explicit throttling guidance.
Parameter 'limit' in search_monologues and list_all_monologues_for_a_character has a max of 100 and 200 respectively, but there is no documented rationale or guidance on why these caps exist. For LLMs choosing limits, context is critical, explain whether the limit prevents API overload, token exhaustion, or response parsing complexity.