Designers

Usability numbers

usability_stats

Read-only

Usability arithmetic with formulas shown. mode sus: score System Usability Scale responses (rows of ten 1-5 answers) with grade, percentile and 95% interval. mode discovery: participants needed to find a share of problems (Nielsen and Landauer). mode ab: sample size per variant for a conversion test (baseline, lift in percent, optional dailyVisitors). mode survey: responses needed for a margin of error.

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": "usability_stats"
  }
}

Input Schema

Name	Required	Description
`p`	No	discovery: chance a participant hits a problem, default 0.31
`lift`	No	ab: smallest relative lift to detect, percent
`mode`	No	Which calculator
`alpha`	No	ab: significance level, 0.1, 0.05 or 0.01
`power`	No	ab: 0.8, 0.9 or 0.95
`margin`	No	survey: margin of error, e.g. 0.05
`target`	No	discovery: share of problems to find, default 0.85
`baseline`	No	ab: current conversion rate, e.g. 0.05
`responses`	No	sus: array of 10-number arrays
`confidence`	No	survey: 0.9, 0.95 or 0.99
`population`	No	survey: total population, for the finite-population correction
`dailyVisitors`	No	ab: traffic per day, to estimate how long to run

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish this as a read-only, closed-world, non-destructive operation, and the description adds useful output behavior: formulas are shown, sus returns a grade/percentile/interval, and ab can use dailyVisitors to estimate run time. It does not cover invalid-input behavior, but for a local calculator the added behavioral context is solid.

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

Conciseness5/5

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

The description is compact and front-loaded, opening with the tool's purpose and then mapping each mode in a single efficient sentence. Every sentence contributes mode-specific information, with no filler.

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 12-parameter, multi-mode calculator with no output schema, the description covers all four modes and the key returned values, including formulas shown. Together with the fully described input schema and annotations, an agent has enough information to select and invoke the tool correctly.

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, and the description adds mode-level grouping that helps the agent know which parameters belong together, e.g. ab with baseline/lift/dailyVisitors and sus with rows of ten 1-5 answers. It does not explain every parameter such as alpha, power, confidence, or population, but those are covered by 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?

The description states exactly what the tool computes and enumerates four concrete modes: SUS scoring, discovery sample size, A/B sample size, and survey response count. Each mode names the specific output, such as grade/percentile/95% interval, so the agent can distinguish it from the sibling audit and lint tools without opening the schema.

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 mode-by-mode descriptions make clear when each branch is appropriate: use sus for scoring response rows, discovery for Nielsen/Landauer problem-discovery estimates, ab for conversion-test sizing, and survey for margin-of-error planning. There are no explicit exclusions or alternate tools, but the usage context for each mode is clear.

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

All Designers tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?