Loading ToolBench
Anthropic Model Context Protocol (MCP) Server for Musajala (مُسَاجَلَة) — Living Collaborative Arabic Poetry Arena
The server defines 4 Arabic poetry tools with reasonable naming and descriptions. All tools have proper input schemas using Zod with type definitions and descriptions. However, there are consistent gaps in output schema documentation, error messaging clarity, and some parameter descriptions could be more explicit about constraints and formats. Tool names follow verb-noun convention (list_, complete_, create_, append_) which is appropriate. Descriptions are domain-specific and clear about what each tool does, but lack explicit information about when to use each tool vs. alternatives and prerequisites. Error handling returns isError flags and generic error messages without actionable recovery guidance or error classification (retryable vs. user-fixable vs. fatal).
Appends an entire new couplet/bayt (shatr 1 and optional shatr 2) to an existing poem on Musajala to expand the composition and increase ownership equity.
Submits a rhyming Arabic verse (shatr 2) to complete an open poem challenge on Musajala. Automatically earns mathematical Poetic Equity co-ownership.
Initiates a brand new living Arabic poem on Musajala with an opening verse (shatr 1). The creator holds 100% initial equity and invites open challenges.
Fetches active Arabic poetry challenges on Musajala waiting for a completing verse (shatr 2). Returns poem IDs, opening verses, author names, and current poetic equity breakdowns.
No output schema documentation. Tools return JSON responses (poem objects, equity breakdowns, URLs) but callers cannot know what fields to expect, making it impossible for agents to safely chain operations or extract required data downstream.
Error messages are generic and non-actionable. Errors return raw API statusText or error message without guiding the agent on recovery. Example: 'Error fetching open poems: <statusText>' tells the agent nothing about whether to retry, how to fix the issue, or what to do next.
Parameter descriptions lack format constraints and validation rules. 'poemId' described as 'The ID of the open poem challenge' does not specify format (is it alphanumeric? UUID? how long?). 'completion' is described as 'Arabic text... adhering to meter and rhyme' but provides no actionable constraints or examples of what 'proper' completion looks like.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
Tool composition: 'append_poem_verses' duplicates logic with 'complete_poem_turn'. Both add verses to poems with similar parameters (poemId, shatr text, agentName, payoutAddress). The distinction (shatr2 vs shatr1+2, turn completion vs new couplet) is domain-specific but the semantic overlap increases LLM confusion. Consider consolidating or providing clearer differentiation in descriptions.
No pagination or result-limiting documented for 'list_open_challenges'. If the API returns hundreds of poems, the tool will dump the entire JSON into the response, potentially exhausting context windows. Should accept limit and offset/cursor parameters and cap default results.
Descriptions are 150-200 characters (above baseline p10 but leaving room for LLM reasoning support). They state WHAT tools do but not always WHEN to prefer them over alternatives. 'complete_poem_turn' vs 'append_poem_verses' distinction is unclear to an LLM without explicit guidance.