Loading ToolBench
MCP server for Nager MCP UI API with HTTP 402 payment protocol support
Server has 3 tools with READ_ONLY operations. All tools have descriptions and input schemas visible in server.py. However, tool names violate fundamental naming conventions (should start with action verbs like 'get_', 'list_', 'search_'), descriptions contain example values that LLMs will reuse literally, parameter descriptions lack format constraints and validation guidance, and output schemas are completely undocumented. The codebase is incomplete, tool implementations are stubbed with '# Tool implementations will be added here' comment, and only the first tool has a partial decorator (@require_payment_for_tool) visible. Error handling is not evident in the visible code. Security concern: API keys appear to be handled via environment variables (SERVER_ADDRESS, MCP_OPERATOR_PRIVATE_KEY) which is correct, but no evidence of input validation or error guidance in responses.
A long weekend is calculated based on public holidays that create an extended break of at least three consecutive days. Optional bridge days-weekdays between a holiday and a weekend-can be included to identify potential extended leave opportunities.
This endpoint returns all countries for which public-holiday data is available. Each entry includes the country's name and ISO code.
Provide a valid `ISO 3166-1 alpha-2` country code to retrieve country metadata. The response includes commonly used and official country names, the assigned region, and if available neighboring countries based on geographical borders.
Tool names do not start with action verbs. Names like 'retrieves_detailed_information_about_a_specific_country' are verbose, passive, and violate the verb_noun convention (should be 'get_country_info'). LLMs rely on name-first parsing to infer action, these names force deep reading of descriptions. Baseline: 90% of A+ tools start with a verb; these 0/3 do.
Parameter descriptions lack format constraints and validation rules. Example: countryCode parameter description says 'The 2-letter ISO 3166-1 country code (e.g., "US", "GB")' but does not state that input must be uppercase, must be exactly 2 letters, or what happens with lowercase input. LLMs cannot parse JSON Schema pattern fields, they rely on description text to understand constraints. Baseline: constraints must be stated in descriptions per pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No output schemas documented anywhere. Tools have READ_ONLY risk designation but their response structures are not defined. LLMs cannot plan downstream tool calls or extract required fields without knowing what the API returns. Baseline: 100% of A+ tools have documented return types.
Tool implementations are incomplete/stubbed. Source code contains comment '# Tool implementations will be added here by endpoint_implementer_crew'. Only the first tool has a partial @require_payment_for_tool decorator visible; actual implementation body is cut off in the provided source. Cannot verify error handling, input validation, or response formatting.
No error handling guidance visible. Tools call external API (https://date.nager.at) with 30-second timeout, but visible code does not show error classification, recovery guidance, or actionable error messages. Pattern requires: 'Error responses must tell the LLM what to do next.' Current code does not demonstrate this.
Description includes example values (e.g., 'US', 'GB') which LLMs will reuse literally rather than adapting to context. Baseline: 'Do not put example values in the description. LLMs tend to reuse example values literally.' Replace with enum or pattern constraints in schema.
No pagination support documented or evident. 'retrieve_the_complete_list_of_all_countries_supported_by_the_nagerdate_api' has no limit, offset, or page parameters, and description does not state how many results are returned. Pattern requires: 'Tools returning lists should accept page/offset and limit parameters.' Even if the Nager API returns a small fixed set, the tool should declare whether results are complete or capped.