Loading ToolBench
A small MCP server for the boring-but-essential utilities: dates, calendars, arithmetic, unit conversion.
Gnomon MCP provides four utility tools with clear, concise descriptions and reasonable input schemas. Tools are well-named (verb-starting: 'now', 'calendar', 'calc', 'calc_convert') and all have descriptions between 80-180 characters, fitting the production baseline (p10=34, p90=392). Input schemas are present and typed. However, several critical gaps reduce the score: (1) No output schemas documented for any tool, LLMs must infer response structure from descriptions alone. (2) Parameter descriptions are minimal or absent in some cases (e.g., 'calendar' tool takes 'ops' array but provides no examples or guidance on operation structure). (3) No error handling guidance, tools may fail silently (e.g., invalid timezone, malformed expression) without clear recovery paths. (4) STDIO transport caps protocol readiness at 50, preventing a higher definition score.
Eval Python expressions -> list. Pre-loaded: math, statistics (mean/median/stdev/variance), abs/round/min/max/sum/range/sorted.
Convert value between units (Pint). E.g. ('meter','foot'), ('kg','lb'), ('degC','degF').
Batch date ops: [{"op": NAME, ...args}, ...] -> [result, ...] diff(start, end, unit) until(target, unit, tz?) since(source, unit, tz?) -> float add(date, n, unit) -> ISO weekday(date) -> name business_days(start, end) -> int (Mon-Fri, end exclusive) parse(natural, tz?) -> ISO format(date, fmt) -> str unit: seconds|minutes|hours|days|weeks (+ months|years for add).
Current moment as dict (iso, date, weekday, week_of_year, quarter, fiscal_year_us_gov, is_weekend, ...). Optional IANA tz.
No output schemas documented for any tool. LLMs cannot infer response structure, fields, or types. The 'now' tool returns a rich dict with 17+ fields (iso, date, time, unix, tz, year, month, month_name, day, weekday, weekday_num, day_of_year, week_of_year, quarter, fiscal_year_us_gov, hour, minute, second, is_weekend) but this structure is never formally specified. Agents must reverse-engineer the response shape from the description alone, risking misuse.
'calendar' tool description is vague and incomplete. It claims to support batch operations (diff, until, since, add, weekday, business_days, parse, format) but provides NO guidance on operation structure, parameter order, or error handling. The 'ops' parameter description says 'Sequence of operation dicts, each with an op key and operation-specific arguments' but does NOT specify what each operation dict looks like, what arguments each operation accepts, or what it returns. This forces LLMs to guess or hallucinate operation schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
No error handling guidance. The 'calc' tool evaluates arbitrary Python expressions, it can fail in many ways (SyntaxError, NameError, ZeroDivisionError, OverflowError). The code raises ValueError with messages like 'expression {i} ({expr!r}) failed: {e}', but the tool description makes no mention of failure modes or recovery. An LLM that passes an invalid expression gets a generic error and has no guidance on what went wrong or how to fix it. Similarly, 'calc_convert' can fail if units are incompatible ('meter to dimensionless' is nonsensical) but offers no hint to the LLM about valid unit families.
'calc' tool exposes Python eval() on a restricted namespace, which is a security concern if the MCP server runs in a multi-tenant or untrusted environment. While the namespace is pre-filtered and __builtins__ is disabled, eval() itself remains a high-risk operation. No mention of limits (execution timeout, memory ceiling, expression complexity) to prevent DoS attacks (e.g., nested exponentials, infinite loops, massive memory allocation). A rogue agent could craft expressions designed to hang the process or exhaust resources.
'now' and 'calendar' tools accept optional timezone parameters but provide no guidance on valid values (e.g., 'America/Los_Angeles' vs 'PST' vs 'UTC-8'). The code uses ZoneInfo(tz) which expects IANA timezone names, but invalid names raise ZoneInfo.UnknownTimeZoneError. The tool description should list valid timezone formats or provide recovery guidance (e.g., 'If timezone is not recognized, try a standard IANA name like America/Los_Angeles').
'calendar' tool operation names are NOT documented as an enum. The description lists operation names as prose ('diff', 'until', 'since', 'add', 'weekday', 'business_days', 'parse', 'format') but LLMs cannot extract a formal enumeration. A formal enum constraint in the schema would prevent hallucinated operation names (e.g., 'duration', 'duration_between', 'time_since').
'calc_convert' tool accepts unit names as free-form strings (e.g., 'meter', 'foot', 'kg', 'lb', 'degC', 'degF'). The description provides examples but no constraint. Pint's UnitRegistry supports hundreds of units, but invalid unit names silently fail or raise obscure Pint exceptions. The tool should document valid unit families (length, mass, temperature) or link to Pint's unit registry, or accept an enumerated set of common conversions.