Zovo Sign-In Sheets

Generate sign-up sheet

generate_sign_up_sheet

Read-onlyIdempotent

Use this when the user wants a sign up sheet template to print, either a volunteer sign up sheet with time slots and a number of spots per slot, or a potluck sign up sheet with items (main dish, salad, dessert) and spots per item. Slots can be listed or built from a start time, end time and slot length. Returns a print-ready PDF with rows filling the page and a CSV template. Does not run an online sign-up, send reminders or check who signed up.

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

Input Schema

Name	Required	Description
`date`	No	Date printed in the header, in any common form, e.g. "2026-11-14", "Nov 14 2026" or "11/14/2026" (read as US month/day). Leave out to print a blank Date line.
`rows`	No	Number of writing rows, e.g. 25 or "40 rows". Leave out to fill one page exactly. More rows than fit continue on more pages, each page full; "20 per page" sets rows per page.
`items`	No	Potluck or supply items, e.g. "Main dish x3, Salad x2, Dessert x2, Drinks, Plates and cups". "x3", "(3)" or ": 3" after an item sets how many people can sign up for it.
`pages`	No	Number of identical blank pages when no list is given, 1 to 50, e.g. 3. Default 1.
`title`	No	Heading printed at the top, e.g. "Board Meeting Sign-In" or "Fall Open House". Default depends on the sheet type.
`columns`	No	Column headings to use instead of the defaults, as a list or comma separated text, e.g. ["Name", "Email", "Phone", "Signature"]. Any names work; widths follow the content (Email wide, Time In narrow, a "?" column is a tick box).
`teacher`	No	Coordinator or host name printed in the header, e.g. "Sam Lee".
`end_time`	No	Volunteer: last slot end, e.g. "5pm" or "17:00".
`location`	No	Location printed in the header, e.g. "Room 204" or "Community Hall". Leave out for a blank line.
`numbered`	No	Print a # column with row numbers, e.g. true. Default true for sign-in, contact and attendance sheets.
`org_name`	No	Organization, school or business name printed above the title, e.g. "Maple Street PTA".
`striping`	No	Light gray shading on alternate rows (or alternate groups), e.g. false for plain rows. Default true.
`subtitle`	No	Optional second line under the title, e.g. "Quarterly review, 6 pm".
`page_size`	No	Paper size: "Letter" (default, 8.5x11), "A4" or "Legal". "A4 landscape" also sets the orientation.
`sheet_type`	No	"volunteer" (time slots with spots for names; default) or "potluck" (items people bring, with spots per item).
`start_time`	No	Volunteer: first slot start, e.g. "9am" or "09:00".
`time_slots`	No	Volunteer slots, one per item or line, e.g. ["9:00-11:00", "11:00-1:00", "1:00-3:00 x4"]. "x4" or "(4)" after a slot sets its spots. Or give start_time, end_time and slot_length instead.
`orientation`	No	"portrait" or "landscape", e.g. "landscape". Default portrait (visitor logs and attendance sheets: landscape). Switches to landscape by itself when the columns do not fit.
`slot_length`	No	Volunteer: slot length, e.g. "2 hours", "90 min" or 120 (minutes). Default 1 hour.
`instructions`	No	One line of instructions under the header, e.g. "Please print clearly". Each type has a default; "none" removes it.
`extra_columns`	No	Columns to add to the defaults, e.g. "Dietary needs" or ["T-shirt size", "Initials"].
`spots_per_slot`	No	Name spots under each slot or item that has no number of its own, e.g. 3 or "3 volunteers". Default fills the page.

Output Schema

Name	Required	Description	Default
`label`	Yes
`notes`	Yes
`pages`	Yes
`title`	Yes
`groups`	Yes
`assumed`	Yes
`columns`	Yes
`downloads`	Yes
`page_size`	Yes
`blank_rows`	Yes
`sheet_type`	Yes
`total_rows`	Yes
`names_count`	Yes
`orientation`	Yes
`print_check`	Yes
`date_columns`	Yes
`row_height_in`	Yes
`rows_per_page`	Yes
`prefilled_rows`	Yes
`links_expire_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive, so the description is not carrying the safety burden. It adds genuinely useful behavior beyond them: the output artifacts (print-ready PDF plus CSV template), the two supported sheet types, and the explicit non-capabilities. It does not state page/fill constraints such as the 1-50 page cap, which the schema covers anyway.

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 the trigger, then the two variants, then the output and exclusions. Almost every clause earns its place; the parenthetical item examples ('main dish, salad, dessert') are illustrative padding that duplicates what the schema's items property already shows.

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?

For a 22-parameter, all-optional tool with an output schema, the description supplies the right level of orientation: what the two modes are, what comes back, and what the tool will not do. The notable omission is explicit steering against the sibling sign-in and attendance generators, which share much of the same surface.

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% and every parameter already carries examples and defaults, so the baseline is 3. The description reinforces the volunteer-vs-potluck distinction (time slots vs items) and the 'slots listed or built from start/end/length' alternative, which helps an agent pick a parameter strategy, but it adds no syntax or constraint detail beyond what the schema already documents.

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?

States a specific verb and resource ('generate a sign up sheet template to print') and enumerates the two output variants (volunteer with slots, potluck with items). It never names the sibling tools generate_sign_in_sheet or generate_attendance_sheet, so an agent must infer the boundary from the volunteer/potluck framing rather than being told explicitly.

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?

'Use this when the user wants a sign up sheet template to print' gives a clear triggering condition, and the closing sentence gives concrete exclusions (no online sign-up, no reminders, no tracking who signed up). It stops short of naming alternatives for the adjacent cases, so routing against sibling sheet generators is left to inference.

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

All Zovo Sign-In Sheets 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?