Zovo Maze Maker

Generate printable mazes

generate_mazes

Read-onlyIdempotent

Use this when the user wants printable mazes (maze generator, maze puzzles, maze worksheets, circle maze, hexagon maze) as a PDF with an answer key. Put one object per maze in mazes[] when the mazes differ (shape, difficulty or size, age); for a set of the same kind, set count with shape and difficulty, or pass the child's age. Each maze has a single solution (only one path from Start to Finish, checked by a breadth-first search); the PDF has 1, 2 or 4 mazes per page on Letter or A4, an optional title and name line, and answer pages with the path drawn. Defaults: 1 medium rectangle maze, Letter, 1 per page, name line and answer key on. Does not make picture-shaped mazes, mazes with several solutions, or solve a maze from a photo.

Input Schema

Name	Required	Description
`age`	No	Age of the solver; picks the difficulty when none is given (4 and under very easy, 5 to 7 easy, 8 to 10 medium, 11 and up hard). Example: 7
`seed`	No	Starting seed; maze N uses seed + N - 1. Reuse it to reprint the same mazes. Example: 2026
`size`	No	Grid size for all mazes instead of a difficulty: "columns x rows" (rectangle, hexagon) or rings (circle). Example: "12x16"
`count`	No	How many mazes when they are all the same kind (1 to 20, default 1). Example: 4
`mazes`	No	One object per maze when the mazes differ, e.g. [{"shape":"circle","difficulty":"easy"},{"shape":"rectangle","size":"20x25"}]. Leave out and use count for a set of the same kind. Up to 20.
`paper`	No	letter (default, US 8.5 x 11 in) or a4. Example: a4
`shape`	No	Shape for all mazes: rectangle (default), circle (round theta maze) or hexagon. Example: circle
`title`	No	Title printed at the top of each page. Example: Space Explorer Mazes
`per_page`	No	Mazes per printed page: 1 (default), 2 or 4. Example: 2
`algorithm`	No	backtracker (default) or wilson. Example: backtracker
`name_line`	No	Print a Name and Date line on the maze pages (default true). Example: false
`answer_key`	No	Add answer pages with the solution path drawn (default true). Example: true
`difficulty`	No	Difficulty for all mazes: very easy, easy, medium (default), hard or expert. Example: easy

Output Schema

Name	Required	Description	Default
`count`	Yes
`mazes`	Yes
`notes`	Yes
`pages`	Yes
`paper`	Yes
`title`	Yes
`per_page`	Yes
`downloads`	Yes
`name_line`	Yes
`answer_key`	Yes
`maze_count`	No
`all_perfect`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial context beyond that. It discloses single-solution validation via breadth-first search, PDF layout defaults, answer-page behavior, and unsupported maze types.

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 front-loaded with the primary use case and then packs structural guidance, defaults, and limits into a compact space. Despite its length, every sentence contributes to selecting or configuring the tool.

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 13-parameter generator with an output schema and rich annotations, the description covers usage, defaults, limitations, and parameter relationships. It does not need to explain return values because an output schema exists.

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 description coverage is 100%, so the schema already carries most parameter meaning. The description adds useful cross-parameter guidance about mazes[] versus count and shape/difficulty sets, though it mostly repeats defaults already present in 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 a specific resource and output: printable mazes as a PDF with an answer key. It enumerates supported shapes and formats, and it explicitly distinguishes what it does not create, such as picture-shaped mazes or multi-solution mazes.

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?

It gives clear when-to-use guidance and explains the key alternative input pattern: use mazes[] when mazes differ versus count for a same-kind set. It also provides defaults and explicit exclusions, leaving little ambiguity about when this tool applies.

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

All Zovo Maze Maker 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?