Printablesmith

Make any printable

make_printable

Read-onlyIdempotent

Make a sheet on any maker page of the site, with any of its settings: calendars, planners and checklists, logs, graphic organizers (Venn diagram, KWL chart…), name tags and desk plates, raffle tickets, coupon books and hall passes, games (bracket, fortune teller, charades, would you rather), bubble letters and banners, lined, graph, dot and handwriting paper, multiplication, addition, division and hundreds charts, number lines, place value charts, fraction strips, sight word sheets, color by number, and every maker that has its own tool. Prefer a maker’s own make_* tool when it has one. Call describe_maker first to see a page’s settings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "page": "<page>"
    },
    "name": "make_printable"
  }
}

Input Schema

Name	Required	Description
`page`	Yes	The maker page, e.g. /weekly-planner/ or /graph-paper/.
`seed`	No	Which random version to make. Leave out for a fresh one; pass the seed from an earlier result to keep that version while changing other settings.
`items`	No	The maker’s typed list (describe_maker says what it is), one entry each.
`names`	No	Optional names, one sheet each, for makers that take names (name tags, certificates, word searches, charts; first names are enough). Shown and printed in the chat only: the link never carries names, so a person opening it types them on the page.
`paper`	No	Paper size: letter (US Letter, the default; US and Canada) or a4 (everywhere else).
`title`	No	The title printed on the sheet, where the maker prints one.
`settings`	No	Address keys and values to change, exactly as describe_maker lists them.

Output Schema

Name	Required	Description
`url`	Yes	The sheet on printablesmith.com, every setting filled in: open it to adjust, download the PDF or print
`seed`	No	The seed that rebuilds this exact sheet
`maker`	Yes	Which maker drew it, e.g. wordSearch
`notes`	Yes	Things worth knowing about this sheet
`title`	Yes	The sheet title
`playUrl`	No	Where a child can solve it on a screen (word search, crossword, maze, sudoku)
`summary`	Yes	What the sheet is
`settings`	Yes	The address settings, as the maker reads them

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered in structured data. The description adds no behavioral context beyond that: it says nothing about what is produced, whether the sheet is stored, or how the returned link relates to the generated content. With annotations carrying the burden, this is a thin contribution.

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

Conciseness3/5

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

The opening verb phrase and the two trailing guidance sentences are well-placed and load-bearing. However, the middle is a bloated enumeration of roughly forty maker types (charades, would you rather, coupon books, hall passes) that adds little beyond 'any maker page' and buries the actionable guidance.

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?

All seven parameters are documented in the schema, an output schema exists, and annotations cover the safety profile, so the description only needs to supply routing logic, which it does. The one gap is that it doesn't clarify the relationship between the generic tool and the specific maker tools' outputs.

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, but the description adds real meaning by pointing the agent to describe_maker as the authority for valid `settings` keys and by framing the tool as applicable 'with any of its settings'. That routing guidance helps an agent use the open-ended `settings` object correctly.

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 uses a specific verb and resource ('Make a sheet on any maker page of the site') and positions the tool as a generic fallback that covers every maker category. It partially differentiates itself from siblings by telling the agent to prefer a maker's own make_* tool, though it never names one of the actual siblings directly.

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 states the alternative selection rule explicitly ('Prefer a maker's own make_* tool when it has one') and gives the required prerequisite step ('Call describe_maker first to see a page's settings'). An agent knows both when to use this tool and what to do before calling it.

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

All Printablesmith 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?