Loading ToolBench
The server defines 2 tools with visible schemas in index.js. Both tools have descriptions and Zod-based input schemas. However, the descriptions are minimal (72-174 chars), parameter descriptions are generic, output schemas are not documented, and there is no error handling guidance. Tool naming follows verb_noun convention but descriptions lack LLM-optimized context about when to use each tool vs. alternatives. No structured output schema documentation, no pagination info, and error responses are unguided plain text. The 3 prompts are basic template-based helpers without depth.
Helps find Iranian (Persian) holidays, cultural events, or important dates based on a Persian name or keyword. Useful for answering user questions about national or Islamic events.
Provides structured calendar data based on a given date. Outputs Jalali (Persian), Gregorian, and Hijri calendar information, including Iranian national holidays, Islamic events, and seasonal metadata.
Output schemas not documented. Both tools return text content in a simple structure, but no schema definition explains what the response contains, field types, or structure. LLMs cannot predict output shape for downstream planning.
Tool descriptions are too brief and lack LLM-selection context. 'Provides structured calendar data...' (72 chars) does not explain when to use jalaliCalendar vs. other date tools or what data fields are returned. 'Helps find Iranian holidays...' (174 chars) does not clarify whether it accepts partial Persian names, how results are ranked, or if it returns event dates.
Parameter descriptions are minimal. The 'date' parameter says only 'ISO 8601 date string (example: '2025-05-08')', no guidance on timezone handling, whether future dates are valid, or behavior on invalid dates. The 'query' parameter says 'Event name or part of it, in Persian (Farsi) text', but does not specify if it accepts partial matches, is case-sensitive, or requires transliteration.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No error handling guidance. If getDateinformation() or SearchEvents() fails, the code returns plain text with no recovery hints. An LLM receives 'Invalid date' with no suggestion to validate format or retry, it cannot self-correct.
No structured output schema. Tools return `{ type: 'text', text: '...' }` with unstructured plain-text content. No documented schema tells the LLM what fields to expect (e.g., do calendar responses include holiday names, dates, descriptions, or all three? In what format?).
No pagination or result limits documented. findHolidayOrEvent may return many matches for a common query (e.g., 'نوروز' / Nowruz) but no cap or pagination mechanism is described. This invites context window exhaustion.
Resource description is trivial. The 'date' resource says 'get currect date and time in IOS format' (with spelling error 'currect'). No guidance on when to use this vs. calling jalaliCalendar with today's date, or what the ISO format guarantees (timezone, precision).
Prompt descriptions are generic boilerplate. 'User asks for today's date and calendar information' does not explain the difference from 'specific-date-information' or why an agent should invoke one vs. the other. Descriptions do not reference tool names or explain composition.