Skip to main content
Glama

Show typing test

show_typing_test
Read-onlyIdempotent

Use this when the user wants to take a typing test, check their typing speed (WPM), practice typing, test on their own paragraph, or drill weak keys. Opens a live test in the widget: the timer starts on the first keystroke, characters are highlighted as typed, and the widget scores the result with calculate_typing_score. Returns the passage settings and a challenge link that opens the same test in a browser. Does not score text by itself and does not save results between conversations. Do not use for counting words in a document or for typing tutorials without a test.

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

Input Schema

NameRequiredDescriptionDefault
modeNotimed (type until the clock runs out) or passage (type one full passage; time stops at the last character). Defaults to timed, or passage when custom_text is given. Example: timed.
seedNoOptional number that picks the passage; the same seed and settings give the same passage (for retakes and fair challenges). Example: 4821.
difficultyNoPassage style: words (common English words, no punctuation), sentences (prose with capitals and punctuation), numbers (words mixed with numbers, times and dates), code (short code snippets with line breaks). Default words. Example: sentences.
focus_keysNoPractice drill: the keys to train, e.g. 'eth' or 'q;7' (a list like 'q, z and x' also works). Builds a drill passage from words that use these keys. Usually the weak_keys from a previous result.
custom_textNoText the user wants to be tested on, pasted verbatim, e.g. 'The early bird catches the worm.' Curly quotes and dashes become keyboard characters; whitespace is collapsed (line breaks are kept when difficulty is code). At least 5 characters; text beyond 3,000 characters is cut at a word boundary.
duration_secondsNoLength of a timed test in seconds, 10-600. Common choices are 15, 30, 60, 120; job tests often use 60, 180 or 300. Default 60. Example: 60.

Output Schema

NameRequiredDescriptionDefault
kindYes
modeYes
seedYes
textYes
titleYes
customYes
downloadsYes
char_countYes
difficultyYes
focus_keysYes
word_countYes
text_previewYes
difficulty_labelYes
duration_secondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior: timer starts on first keystroke, live character highlighting, returns passage settings plus a browser challenge link, no self-scoring, and no persistence between conversations. These are exactly the facts an agent needs beyond the safety hints.

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 the usage trigger, then behavior, then boundaries in a logical order. The single long sentence listing use cases is dense but every clause maps to a distinct mode or exclusion; minor tightening possible but nothing is wasted.

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?

Six optional params, an output schema, and four annotations — the description covers the interactive behavior, the scoring handoff, the return payload (settings + challenge link), and the non-persistence caveat. An agent has everything needed to call it correctly.

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 coverage is 100% and each parameter carries its own detailed description with examples, so the schema does the heavy lifting. The description only gestures at parameters indirectly ('test on their own paragraph', 'drill weak keys') without adding format or default details 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?

States a specific verb+resource ('Opens a live test in the widget') with concrete scope: timed WPM testing, custom paragraph, weak-key drills. It explicitly separates itself from the sibling by noting the widget scores results with calculate_typing_score rather than scoring itself.

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

Usage Guidelines5/5

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

Gives explicit trigger conditions ('when the user wants to take a typing test, check their typing speed...'), names the scoring alternative (calculate_typing_score), and lists concrete exclusions ('Do not use for counting words in a document or for typing tutorials without a test').

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