Loading ToolBench
Production read-only MCP server for Project Parva temporal tools.
This MCP server exposes 9 tools for Nepali calendar and temporal operations. While all tools have formal JSON schemas with typed parameters and descriptions present, the quality is inconsistent. Most tool descriptions are generic and lack the LLM-optimization guidance the rubric requires (e.g., 'Check if a given date is a holiday' vs. 'Returns true if the date is a holiday in Nepal; call this before scheduling meetings on potentially restricted dates'). Parameter descriptions exist but are minimal (avg ~20-30 chars, well below the 72-char baseline). No tool declares output schemas explicitly, the rubric requires documented return types for A-grade tools. Error handling guidance is completely absent; there are no recovery hints or actionable error messages visible in the code. Tool naming is acceptable but not optimized: verb_noun convention is mostly followed (get_*, check_*, convert_*), but the tool composition raises concerns. Tools 4-6 (check_holiday, check_working_day, get_fiscal_year) accept redundant parameters (both 'ad_date' and 'bs_date', plus 'profile_id') without clarity on whether these are alternatives or required together, violating the mutual-exclusivity documentation rule. Tool 9 (check_temporal_claim) has an ambiguous contract, it accepts a free-form 'claim' string, which invites hallucinated or invalid inputs that the tool may not support. No parameter constraints (enums, min/max) are visible for most tools. The server shows no evidence of input validation, error categorization, or recovery patterns. This is a functional calendar API wrapped in MCP form, but lacks the agent-centric design patterns required for reliable autonomous tool use.
Check if a given date is a holiday according to Nepal's public holiday rules.
Check a temporal claim (date, holiday, working day, or festival) and return evidence and review status.
Check if a given date is a working day according to Nepal's business rules.
Convert a Gregorian (AD) date to Bikram Sambat date.
Convert a Bikram Sambat date to Gregorian (AD) date.
Get the date of a specific Nepali festival for a given year.
Get the fiscal year information for a given Bikram Sambat year.
No output schemas documented. The rubric (DIMENSION 1.D) requires documented return types for all tools. Without explicit output field definitions, LLMs cannot plan downstream operations or extract required data reliably.
Ambiguous multi-parameter design for check_holiday, check_working_day, and get_fiscal_year. Each accepts both 'ad_date' and 'bs_date' plus 'profile_id' without documenting whether these are alternatives, mutually exclusive, or all required. Per DIMENSION 1.C, undocumented parameter dependencies cause silent misuse.
check_temporal_claim accepts free-form 'claim' string with no enum constraints or format guidance. This violates DIMENSION 1.C (enum for known values) and invites hallucinated inputs. An LLM cannot determine which claim strings are valid without trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2025-06-18+ | v2 |
Get today's date in Bikram Sambat calendar.
Get Panchanga (Hindu calendar) information including tithi, nakshatra, and other astrological data for a given date and location.
Descriptions are minimal and lack LLM-optimization guidance. Average description length ~40 chars vs. baseline 194 chars. No descriptions answer WHEN to use the tool instead of similar ones, or what dependencies exist. E.g., 'Get today's date in Bikram Sambat calendar' does not explain whether this is timezone-aware, which location, or typical use cases.
No error handling guidance or recovery patterns visible. Per DIMENSION 1.E, error responses must tell the LLM what to do next. No evidence of retryable vs. user-fixable categorization, actionable error messages, or suggestions for alternative tools.
No input validation visible. Parameters like 'month' (1-12) or 'year' lack min/max bounds. Per DIMENSION 1.C, LLMs will pass absurd values (month=99, year=-5000) without explicit range constraints. No validation errors or actionable feedback shown.
Parameter descriptions are too brief. 'Bikram Sambat year' (18 chars) vs. baseline 72 chars. No clarity on format, valid ranges, or edge cases. E.g., 'Gregorian date in ISO format (YYYY-MM-DD)' appears once but not consistently; others just say 'date' without format guidance.
Festival identifier in get_festival_date ('festival_id') has no enum constraint or list of valid values. Per DIMENSION 1.C, LLMs will guess at festival names ('dashain', 'Diwali', 'dussehra') without explicit enumeration, causing failures.
Panchanga proof parameter ('compact', 'audit', 'replay', 'membrane') is properly enumerated but lacks explanation of what each mode does or when to use each. Description is too sparse for agent selection.