Hopi

Ratio calculator

hopi_ratio_calculator

Read-onlyIdempotent

Work with ratios. Mode 'simplify': reduce a ratio a : b to its lowest terms, and give the 1 : n form and the decimal a / b. Mode 'solve': find the missing value x in the equivalent ratio a : b = c : x using cross multiplication. All inputs must be positive. Source: https://hopi.co.uk/ratio-calculator/

Input Schema

TableJSON Schema

Name	Required	Description
`a`	Yes	First term of the ratio (positive)
`b`	Yes	Second term of the ratio (positive)
`c`	No	Known term of the equivalent ratio, mode 'solve' (a : b = c : x)
`mode`	Yes	'simplify' a ratio, or 'solve' for the missing value

Output Schema

TableJSON Schema

Name	Required	Description
`a`	Yes
`b`	Yes
`mode`	Yes
`oneToN`	No
`decimal`	No
`summary`	Yes
`simplified`	No
`source_url`	Yes	The tool's page on hopi.co.uk (cite or open to check the figure)
`simplifiedA`	No
`simplifiedB`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

addedOutput schema / required

Added value: +[
+  "a",
+  "b",
+  "mode",
+  "source_url",
+  "summary"
+]

First observedSep 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral details: all inputs must be positive, simplify outputs lowest terms plus the 1:n form and decimal, and solve uses cross multiplication. It doesn't specify precision or error handling, but the output schema can cover that.

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 compact and front-loaded, with the scope statement first and one sentence per mode. The trailing source URL is mildly extraneous for an agent deciding whether to call the tool, but it doesn't harm clarity enough to reduce the score further.

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?

For a two-mode calculator, the description covers mode selection, parameter roles, the solve equation, and input constraints. The conditional schema and output schema fill the remaining invocation details, so nothing essential 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 useful relational meaning by showing how a, b, and c interact in ratio notation and which parameters apply to each mode. The explicit positivity constraint reinforces the schema's exclusiveMinimum checks.

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

Purpose5/5

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

The description moves beyond the title by defining two concrete operations: simplify a ratio to lowest terms with 1:n and decimal forms, and solve for a missing value in an equivalent ratio using cross multiplication. This clearly identifies the resource and its behavior, distinguishing it from generic calculator siblings.

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

Usage Guidelines4/5

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

The description gives clear context for when each mode should be used: 'Mode simplify' reduces a:b, while 'Mode solve' finds x in a:b = c:x. It does not explicitly mention alternatives among siblings such as hopi_aspect_ratio_calculator, so it stops short of full when/where-not guidance.

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

All Hopi 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?