Safe maths and statistics, and UK working-day arithmetic using official bank holidays
Scored across 2 tools
The two tools target clearly distinct domains: general mathematical evaluation versus UK working-day date calculations. There is no realistic risk of selecting the wrong tool for a given task.
Both names are readable and snake_case, but they use different conventions: 'calculate' is a verb while 'working_days' is a noun phrase. This is a minor inconsistency rather than a serious problem.
Two tools is thin, but the server is explicitly scoped to maths and UK working days, and each tool covers a meaningful operation. The count is reasonable for this narrow purpose.
The surface covers expression evaluation, summary statistics, working-day differences, and working-day date offsets. Coverage is solid for the stated domain, though broader date arithmetic or holiday-listing support is absent.
Evaluate an expression (+ - * / ^ %, sqrt, ln, log, round, min, max, pi) or summary statistics of a list of numbers. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| values | No | array or comma list of numbers | |
| expression | No | string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose a genuinely useful operational detail the schema cannot: the cost of 1 credit per call. It also implicitly reveals the tool is a pure computation with no side effects by listing only math functions. But it says nothing about the return shape for the statistics mode (mean, median, count?), numeric precision, or how invalid expressions are reported, which are the details an agent most needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses front-load the capability and the parenthetical function list is dense but each item earns its place by defining the accepted grammar. The cost note is appended efficiently rather than buried. Minor deduction because the parenthetical enumeration slightly crowds the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should close the loop on what a statistics call actually returns, and it does not — the word "summary statistics" is left undefined. For a simple two-parameter computation tool the coverage is close to adequate, but the missing return-value detail is the one gap that could force a trial call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description earns above that by supplying the expression grammar — the allowed operators and functions (sqrt, ln, log, round, min, max, pi) — which the schema only labels as an untyped "string". It also clarifies that "values" is a number collection, consistent with the schema's "array or comma list of numbers".
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ("Evaluate") and two concrete resource modes (an expression, or summary statistics of a number list), and it enumerates the supported operators and functions, which tells an agent exactly what the tool can compute. It does not differentiate against near-neighbours like text_stats or convert_units, but the sibling list is largely unrelated utilities, so the purpose is still unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two operating modes are stated, and by implication "expression" drives the expression mode while "values" drives the statistics mode, so an agent can infer which parameter to populate. However, there is no explicit when-to-use framing, no statement of what happens if both parameters are supplied, and no note on which statistics are produced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK working days between two dates, or the date N working days after/before a date, skipping weekends and bank holidays. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD | |
| from | No | YYYY-MM-DD, required | |
| addDays | No | number | |
| division | No | england-and-wales|scotland|northern-ireland |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the UK-only scope, the weekend/bank-holiday skipping behavior, and a 1-credit cost, but says nothing about the default division when omitted (presumably england-and-wales), error behavior for invalid dates, or what result type is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence covering both modes, the skipping rule, and the cost note. No filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculator-style tool with no annotations and no output schema, the description should clarify the return shape (an integer count versus a YYYY-MM-DD date) and the mutual exclusivity of 'to' versus 'addDays'. Those gaps leave the agent guessing about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema text is thin ('number' for addDays, no default for division). The description compensates by redefining addDays as a count of working days rather than calendar days, which is real added meaning, though the division parameter's region options and defaults go unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: computing UK working days, with the two supported modes spelled out (count between two dates, or offset by N working days). It clearly distinguishes itself from the bank_holidays/public_holidays siblings by noting weekends and bank holidays are skipped, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two operational modes are described, which implicitly tells the agent when each applies, but there is no explicit guidance on choosing this over bank_holidays/public_holidays, and no statement about which mode is chosen if both 'to' and 'addDays' are supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculateworking_daysBusiness-day and public-holiday math for 29 countries: add business days, days between, holidays.
Public holidays for 150+ countries, business-day maths and timezone lookup
UK working days, bank holidays, HMRC and Companies House deadlines.
US federal holidays, business-day maths, invoice due dates and IRS deadlines.
Add one secure layer between your agents and this server.