CalculatorLib

run_calculator

Read-onlyIdempotent

Run a calculator and get the result. Pass the calculator's name (from search_calculators) and its input fields in args. Returns the computed values plus a share link to the calculator page with inputs pre-filled; calculators backed by a legal edition also return edition, effective_from and sources[] (document, article/clause, URL) to cite. Missing inputs are refused (isError), never defaulted. When the calculator has a formula, the result ALSO includes formula_latex — the formula with the user's values substituted; show it to the user (rendered as LaTeX when your client supports it, otherwise inline as text). Example: {"name":"bmi_calculator","args":{"unitSystem":"metric","weight":70,"height":175}}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "args": "<args>"
    },
    "name": "run_calculator"
  }
}

Input Schema

Name	Required	Description
`args`	Yes	Input fields for the calculator (from the search result's inputSchema or get_calculator_schema).
`lang`	No	Optional language for labels, titles and number formatting: en, es, vi, hi, ja, ko, tr, ar, ru, fr, zh, tw, pt, de (zh = Simplified, tw = Traditional Chinese; zh-CN / zh-TW / vi-VN style tags are accepted). Default: en.
`name`	Yes	Tool name from search_calculators, e.g. compound_interest_calculator.
`timezone`	No	Optional IANA time zone of the user (e.g. Asia/Seoul, America/New_York) or offset (+09:00): date calculators count "today" in it. Default: the time zone of the lang's country (en = America/New_York).

Output Schema

Name	Required	Description
`url`	No	Share link: the calculator page with these inputs pre-filled.
`data`	Yes	Secondary result cells.
`main`	Yes	Headline cells {label, value, unit?}.
`edition`	No
`sources`	No	{title, section, cite, url}
`warning`	No
`warnings`	No
`data_used`	No	Real-data figures used, with source and date.
`data_status`	No
`layer_status`	No
`formula_latex`	No	Formula with the caller's values unless formula_values is false.
`rendered_text`	No	Plain-text result when main and data are empty.
`effective_from`	No
`formula_values`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it discloses the return payload (computed values, a share link with pre-filled inputs, legal-edition fields edition/effective_from/sources[] for citation, formula_latex when a formula exists) and states a hard failure behavior ("Missing inputs are refused (isError), never defaulted"). It also instructs the agent to surface formula_latex to the user, which is behavioral guidance no annotation could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and the return contract, and the closing example earns its space by showing the nested args shape. It is dense but every sentence carries information; the parenthetical localization/rendering hints are the closest thing to padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists, the description supplies the semantic layer an agent needs to act on the response — which fields to cite for legal editions and that formula_latex should be displayed. Combined with the failure-mode contract and the input-sourcing chain, nothing required to call or interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that name must originate from search_calculators, that args carries the calculator's own input fields, and it supplies a concrete worked example ({"name":"bmi_calculator","args":{...}}). lang and timezone are only covered by the schema, not the prose, which keeps it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ("Run a calculator and get the result") and the body ties it to the search_calculators workflow by requiring a name from that tool. It does not, however, distinguish itself from solve_math or convert_units, so an agent must infer why it would pick one over the others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: names come from search_calculators and input fields from the search result's inputSchema or get_calculator_schema, which describes a discover-then-run flow. There is no explicit when-to-use/when-not guidance against the sibling tools solve_math and convert_units, so the routing decision for those cases is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CalculatorLib tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?