TuneWorks

Tire Size Comparison Calculator

compare_tire_sizes

Read-only

Compare tire diameter, circumference, ride height, and speedometer change. Calculates from measured inputs without authentication and does not read or save account data. Actual mounted diameter changes by tire model and pressure. Use manufacturer specs when available.

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": {
      "oldWidth": "<oldWidth>",
      "oldAspect": "<oldAspect>",
      "oldWheel": "<oldWheel>",
      "newWidth": "<newWidth>",
      "newAspect": "<newAspect>",
      "newWheel": "<newWheel>",
      "unitSystem": "<unitSystem>"
    },
    "name": "compare_tire_sizes"
  }
}

Input Schema

Name	Required	Description
`newWheel`	Yes	New wheel diameter (in in imperial; mm in metric)
`newWidth`	Yes	New width (mm)
`oldWheel`	Yes	Current wheel diameter (in in imperial; mm in metric)
`oldWidth`	Yes	Current width (mm)
`newAspect`	Yes	New aspect ratio (%)
`oldAspect`	Yes	Current aspect ratio (%)
`unitSystem`	Yes	Units for all inputs and results, as specified on each field.

Output Schema

Name	Required	Description
`url`	No
`note`	No
`tool`	Yes	TuneWorks MCP tool name that produced this result.
`inputs`	No
`result`	No
`status`	Yes	Stable result status such as ok, created, updated, sent, auth_required, or confirmation_required.
`message`	No
`outcome`	No	Optional domain outcome for an otherwise successful read.
`results`	No
`unitSystem`	No
`volumeUnit`	No
`authenticationRequired`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

addedOutput schema / properties / outcome

Added value: +{
+  "description": "Optional domain outcome for an otherwise successful read.",
+  "enum": [
+    "no_vehicles",
+    "vehicle_not_found",
+    "vehicle_selection_required",
+    "no_data"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / status / description

Previous value: -"Result status such as ok, created, updated, sent, auth_required, or confirmation_required."New value: +"Stable result status such as ok, created, updated, sent, auth_required, or confirmation_required."

First observedOct 18, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint=false, so the description earns credit for adding genuinely new context: no authentication required, no account data read or saved, and a real accuracy caveat that mounted diameter varies by model and pressure. It stops short of noting rounding/precision or unit-mixing pitfalls, but the added disclosure is substantive.

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?

Front-loaded with what is compared, then safety and accuracy notes in three short sentences. The authentication/account-data sentence is marginally redundant with the read-only annotations but still informative.

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

Completeness4/5

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

Seven required parameters are fully documented in the schema, an output schema exists to explain return values, and the description covers the accuracy limitation that matters most for a calculator. Missing only explicit scoping against sibling calculators.

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

Parameters3/5

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

Schema description coverage is 100%, with units, ranges, and the unitSystem enum fully documented per field, so the baseline is 3. The description only alludes generically to 'measured inputs' and adds no per-parameter meaning beyond the schema.

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?

Opens with a specific verb and resource ('Compare tire diameter, circumference, ride height, and speedometer change'), naming the exact outputs. This clearly separates it from calculation siblings like calculate_gear_ratio_speed or calculate_tire_pressure_adjustment.

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?

It establishes context ('calculates from measured inputs') and an input-source preference ('use manufacturer specs when available'), but never states when to prefer this tool over a sibling or what inputs would make it inappropriate. Usage is implied rather than guided.

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

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