Printablesmith

Certificate

make_certificate

Read-onlyIdempotent

Make printable award certificates: star student, reading, sports, end of year, kindness, completion and more, with a border, a seal and signature lines. Give names to print one certificate per person (in the chat; the link carries no names, as on the site). award_page starts from one of the site’s ready awards.

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

Input Schema

Name	Required	Description
`ink`	No	The ink color.
`date`	No	A date to print, e.g. "June 5". Leave out for a blank date line.
`seal`	No	A gold seal.
`names`	No	Optional names, one certificate each (first names are enough). Shown and printed in the chat only: like the site, the link never carries names, so a person opening the link types them on the page.
`paper`	No	Paper size: letter (US Letter, the default; US and Canada) or a4 (everywhere else).
`title`	No	The award’s name, e.g. "Star Student" or "Certificate of Achievement".
`border`	No	The border.
`reason`	No	What it is for, under the name, e.g. "for reading 50 books this year".
`date_line`	No	Show a date line (blank unless date is given).
`presented`	No	The line before the name, e.g. "This certificate is proudly presented to".
`award_page`	No	A ready award page to start from.
`signatures`	No	Signature lines: 0, 1 or 2.
`signature_1`	No	The first signature’s label, e.g. "Teacher".
`signature_2`	No	The second signature’s label, e.g. "Principal".
`dyslexia_font`	No	Print in OpenDyslexic, a typeface some readers with dyslexia find easier.

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

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description still adds genuinely non-obvious behavior: names are printed in the chat only and the shared link never carries them, so a recipient types them on the page — a constraint an agent could not derive from the schema or annotations.

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?

Three sentences, front-loaded with purpose and the award categories, then the two behavioral notes that actually matter. Dense but no filler; the parenthetical "as on the site" is the only mildly redundant phrase.

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?

With 15 parameters, full schema coverage, an output schema and rich annotations, the description only needs to supply purpose plus the gotchas, and it does. Paper size defaults, enum values and signature counts are correctly left to the schema, though a note on how output relates to the chat-printed names could close the last gap.

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 a 3 is the floor. The description goes beyond it by explaining the semantics of names (one certificate per person, chat-only, link carries none) and of award_page (starts from a ready award on the site), which are the two parameters whose behavior is least obvious from the schema alone.

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 opens with a specific verb+resource ("Make printable award certificates") and enumerates the occasions it covers (star student, reading, sports, end of year, kindness, completion), which is enough to separate it from the other makers in the sibling list such as make_chart or make_word_search.

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

Usage Guidelines3/5

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

Usage context is implied rather than stated: the agent learns that award_page starts from a ready-made award and that names produce one certificate per person, but there is no explicit "use this when you need X instead of Y" and no sibling is named as an alternative, so routing must be inferred from the topic list.

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?