Loading ToolBench
NerA-MCP has 6 tools with complete input schemas and descriptions, but falls short of production quality. Tool names lack action verbs and are domain-specific rather than following verb_noun conventions. Descriptions are present but generic (averaging ~80 chars, below the 194-char baseline). Parameter descriptions are minimal, and output schemas are not documented. Error handling is present in code but not formally specified. The server demonstrates basic functionality but lacks the LLM-optimized descriptions, comprehensive parameter docs, and output schema documentation that characterize A-grade tools.
Analyze an Arabic name to extract root, lineage, and variants.
Score the credibility of an Arabic news article.
Check if a contract text is Sharia-compliant.
Convert between Hijri and Gregorian calendars.
Extract text and metadata from Arabic document (PDF/Image).
Normalize Arabic dialect to Modern Standard Arabic (MSA) with confidence scoring.
Tool names do not start with action verbs. Names like 'convert_hijri_date', 'analyze_arabic_name', 'normalize_arabic_dialect' are domain-specific descriptors rather than verb_noun patterns (get_, create_, check_, etc.). LLMs rely on verb prefixes to infer intent before reading descriptions.
Output schemas are not documented. Tools return dicts (e.g., analyze_arabic_name returns {root_name, lineage, variants, confidence}; check_sharia_compliance returns {status, ...}), but the MCP tool definitions do not include output schema specifications. LLMs cannot plan downstream calls or validate expected fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | <=2025-11-25 | v2 |
Parameter descriptions are minimal and lack constraints. E.g., 'calendar' param in convert_hijri_date has description 'Source calendar (Hijri or Gregorian)' but does not state valid enum values, case sensitivity rules, or consequences of invalid input. 'school' param in check_sharia_compliance lacks enum specification (Hanafi, Maliki, Shafi, Hanbali not listed).
Tool descriptions are generic and do not guide LLM selection. E.g., 'Score the credibility of an Arabic news article' (57 chars) lacks depth. No explanation of scoring method, scale (0-100?), or when to use vs alternatives. Baseline is 194 chars.
Error handling is coded but not specified in tool definitions. Code returns error strings (e.g., 'Error: Date must be in YYYY-MM-DD format'), but MCP tool definitions do not document error cases, recovery steps, or when errors are retryable. Pattern:recovery-guide not implemented.
No destructive/readOnly hints. All tools are marked READ_ONLY in risk field (correct), but MCP tool definitions do not include toolAnnotations with readOnlyHint, allowing clients to apply UI/safety optimizations.