Zovo Certificate Maker

Generate certificates

generate_certificates

Read-onlyIdempotent

Use this when the user wants to make certificates: a certificate of completion, an award certificate, a certificate of appreciation or participation, or certificates for a whole class or team from a list of names. Returns one print-ready landscape PDF (US Letter or A4) with one certificate per person, a preview, and an optional numbered CSV register. Accepts names as a list, pasted lines, or CSV text with per-person course, award, date or hours; with no names it makes a blank fill-in certificate. Up to 500 certificates per call. Does not make diplomas or licenses that claim accreditation, does not add logos or photos, and does not email or print anything.

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_certificates"
  }
}

Input Schema

Name	Required	Description
`date`	No	Date printed on the certificates in any common form (2026-06-12, June 12 2026, 06/12/2026 read as US month/day). Default today in New York. Use "blank" for a line to fill in by hand.
`award`	No	Award name; it becomes the certificate title. Example: Student of the Month.
`color`	No	Accent colour as a name or hex, e.g. navy, maroon, green, gold or #1D5FC4. Default: the template's colours.
`hours`	No	Hours or credits completed, printed after the course. Example: 8 or "1.5 CE credits".
`paper`	No	Paper size: letter (US Letter, default) or a4. Always landscape.
`title`	No	Custom title that replaces the standard one, e.g. Star Reader Award or Certificate of Training.
`copies`	No	Only for blank fill-in certificates (no recipients): how many copies, 1 to 100. Default 1.
`course`	No	What the certificate is for, used in the description line: a course, program, event or achievement. Example: Introduction to Python.
`signers`	No	Up to 2 signers with name and title. Examples: "Dr. Maria Lopez, Principal; James Carter, Teacher" or [{"name":"Maria Lopez","title":"Principal"}].
`template`	No	Design: classic (double border, corner ornaments), modern (accent bar), academic (rosette seal), kids (bright shapes) or elegant (cream, gold, serif). Default classic.
`recipients`	No	Who gets a certificate: one name, a list of names, pasted lines (one per line), or CSV text with a header row. Optional per-person columns: course, award, date, description, hours. Examples: "Ava Patel", ["Ava Patel", "Liam Chen"], or "name,course\nAva Patel,Python 101". Leave empty for a blank fill-in certificate.
`description`	No	Your own description line instead of the generated one, e.g. for outstanding leadership of the spring food drive.
`organization`	No	Issuing organization printed at the top, e.g. Riverside Elementary School.
`serial_start`	No	First certificate number when serial numbers are on. Default 1. Example: 101.
`serial_prefix`	No	Turns on unique certificate numbers with this prefix, e.g. CERT-2026 gives CERT-2026-0001, CERT-2026-0002. A CSV register of numbers is included.
`include_serial`	No	true to number the certificates even without a prefix (prefix CERT). Default false.
`certificate_type`	No	Kind of certificate: completion, achievement, appreciation, participation, award, excellence, recognition or attendance. Default completion. Example: appreciation.

Output Schema

Name	Required	Description	Default
`pages`	Yes
`paper`	Yes
`title`	Yes
`signers`	Yes
`template`	Yes
`warnings`	Yes
`downloads`	Yes
`assumptions`	Yes
`date_printed`	Yes
`fitted_names`	Yes
`organization`	Yes
`serial_range`	Yes
`blank_name_lines`	Yes
`certificate_type`	Yes
`description_line`	Yes
`certificate_count`	Yes
`recipients_preview`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond them: the 500-certificate-per-call cap, the optional numbered CSV register, the preview, and the explicit 'does not email or print anything' boundary. It does not describe failure behavior when the cap is exceeded or how names in mixed formats are reconciled, keeping it just short of a 5.

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?

Two dense paragraphs, front-loaded with the use case before the output contract and constraints. Every sentence carries information, though the return-value sentence duplicates ground already covered by the output schema and could be trimmed.

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 17-parameter, zero-required tool, the description supplies the output shape, capacity limit, input format flexibility, and explicit non-goals. With an output schema present and full schema descriptions, nothing an agent needs to invoke this correctly is missing.

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. The description still contributes synthesis the schema does not: recipients may arrive as a single name, a list, pasted lines, or CSV with per-person columns, and with no names it emits a blank fill-in certificate. It also ties serial_prefix to the CSV register, which cross-links two parameters.

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 and resource ('make certificates') and immediately enumerates the certificate varieties covered: completion, award, appreciation, participation, and bulk classroom/team sets. An agent can tell exactly what artifact this produces (print-ready landscape PDF, one certificate per person) without opening the schema.

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 explicitly states the trigger condition ('Use this when the user wants to make certificates') and draws firm exclusions: no diplomas or licenses claiming accreditation, no logos or photos, no emailing or printing. With no sibling tools, no alternative routing is needed, so the when/when-not coverage is complete.

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

All Zovo Certificate 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?