Skip to main content
Glama

Fitts and Hick calculator

calc_fitts_hick
Read-only

Estimate movement time with Fitts's law (Shannon form: a + b * log2(distance / width + 1)) and decision time with the Hick-Hyman law (a + b * log2(choices + 1)). Pass distance and width for one target, choices for a choice set, and/or layouts: 2 or 3 layouts, each {name, targets: [{label, distance, width}], choices} to compare total time. Constants are configurable with fitts_a, fitts_b, hick_a, hick_b (milliseconds; defaults a=100, b=150 for pointing and a=200, b=150 for choice, typical illustrative values). These are models: the defaults are not measured on your users, so use results to compare layouts, not to predict seconds. Sources: Fitts 1954, MacKenzie's Shannon formulation, Hick 1952, Hyman 1953, as context in Cooper's About Face and Norman. Constants and laws are stated from general knowledge, not verified against the design library.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calc_fitts_hick"
  }
}

Input Schema

NameRequiredDescriptionDefault
widthNoTarget width along the movement line, same unit.
hick_aNoHick intercept in ms. Default 200.
hick_bNoHick slope in ms per bit. Default 150.
choicesNoNumber of equally likely choices.
fitts_aNoFitts intercept in ms. Default 100.
fitts_bNoFitts slope in ms per bit. Default 150.
layoutsNo2 or 3 layouts to compare.
distanceNoDistance to target along the movement line, any consistent unit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, non-destructive, closed-world), and the description adds the important caveat that defaults are illustrative rather than measured, so results are comparative not predictive, plus it discloses provenance limits ('not verified against the design library'). It stops short of describing the response shape or how results are reported.

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-loads both formulas and the invocation pattern before constants and sources. The closing source/provenance sentence is long and partly redundant with the earlier 'defaults are not measured' caveat, but every paragraph is task-relevant.

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

Completeness3/5

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

For a computation tool with no output schema, the description should say what the result looks like (separate movement/decision/total times? per-layout array?). It only implies 'compare total time', leaving the return structure for the agent to discover at call time.

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 baseline is 3, but the description adds real value by explaining how parameters combine into modes (distance+width = single target, choices = choice set, layouts = comparison) and what the layout structure contains. It also repeats the constant defaults, which the schema already states, so it does not fully earn a 5.

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?

Names the specific models (Fitts Shannon form, Hick-Hyman), gives the actual formulas, and states what is computed (movement time, decision time, total time per layout). No sibling tool computes interaction timing, so it is unmistakable which tool this is.

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?

Explains precisely how to invoke each mode: 'Pass distance and width for one target, choices for a choice set, and/or layouts: 2 or 3 layouts...'. Also scopes appropriate use ('use results to compare layouts, not to predict seconds'). It does not name sibling tools or explicit non-use cases, keeping it below a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources