Zovo Word Guess

Generate word puzzle

generate_word_puzzle

Read-only

Use this when the user wants to make a custom word-guessing game (a 'make your own' five-letter word puzzle) to send to a friend, partner, class, or team: from a secret word they choose (4-8 letters, names allowed) or a random common five-letter word. Optional title and a secret message revealed when solved. Returns a share link anyone can play in a browser and shows the playable puzzle in the widget. The answer and secret message are not included in the reply to you. Does not make crosswords, word searches, or anagram solutions, and does not solve other puzzles.

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

Input Schema

Name	Required	Description
`title`	No	Puzzle title shown above the grid, up to 60 characters, e.g. "Guess our date night". Must not contain the answer.
`answer`	No	The secret word the friend must guess, 4-8 letters A-Z, e.g. PIZZA. Names are fine even if not in the dictionary (e.g. MAYA). Leave it out to use a random common 5-letter word that nobody in the chat knows.
`message`	No	Secret message revealed only after the word is guessed (or all 6 guesses are used), up to 200 characters, e.g. "Happy anniversary! Dinner is at 8."
`allow_any_guess`	No	If true, any letter combination counts as a guess. Default false: guesses must be real English words (the secret word itself is always accepted). Example: true for casual play or non-English words.

Output Schema

Name	Required	Description	Default
`note`	Yes
`title`	Yes
`source`	Yes
`letters`	Yes
`downloads`	Yes
`share_url`	Yes
`guess_rule`	Yes
`max_guesses`	Yes
`has_secret_message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, non-open-world behavior, so the bar is lower; the description still adds real value by disclosing the outputs (a share link plus a widget render) and, critically, that the answer and secret message are not echoed back to the caller — a leak-prevention detail an agent would otherwise not know. It does not explain why idempotentHint is false (each call yields a new puzzle), which is a small remaining gap.

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 trigger phrase, then inputs, then outputs, then exclusions — a logical order in one tight paragraph with no filler. It is on the long side, but each sentence carries either a trigger, a capability, or a boundary.

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?

An output schema exists, so return values needn't be spelled out, yet the description still tells the agent what comes back (share link, widget) and what deliberately does not (the answer, the secret message). Combined with annotations covering safety, the only unaddressed behavior is the non-idempotent/creates-a-new-artifact nature of repeated calls.

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%, so the baseline is 3; the description reinforces the key semantics (4-8 letters, names allowed, omit the answer for a random common five-letter word) but adds no syntax or edge-case detail beyond what the schema already documents. Note the schema itself is internally inconsistent about the title length (60 characters described vs. maxLength 2000), which the description does not resolve.

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

Purpose4/5

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

The description states a specific verb and resource: build a custom five-letter-style word-guessing puzzle from a chosen or random secret word, returning a shareable link and an in-widget playable version. It sharply bounds the domain with explicit exclusions (no crosswords, word searches, anagram solving, or solving other puzzles) — but it never mentions the sibling show_word_puzzle, so the create-vs-display distinction has to be inferred.

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?

Opens with an explicit trigger, "Use this when the user wants to make a custom word-guessing game ... to send to a friend, partner, class, or team," and follows with clear when-not cases (crosswords, word searches, anagram solutions, solving other puzzles). What's missing is a named alternative — no pointer to show_word_puzzle for viewing an existing puzzle.

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

All Zovo Word Guess 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?