Zovo Sign-In Sheets

Generate attendance sheet

generate_attendance_sheet

Read-onlyIdempotent

Use this when the user wants an attendance sheet or class roster template to print, with student or member names pre-filled from a pasted list, with one column per session date (from a list of dates, a start and end date with meeting days, a number of weeks, or a month) or blank date columns, plus a Total column. Long rosters continue on more pages and too many dates split into column sets, with headings repeated. Returns a PDF and a CSV template. Does not take attendance online, calculate grades or store records.

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_attendance_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.
`days`	No	Meeting days, e.g. "Mon, Wed, Fri", "MWF", "Tuesdays and Thursdays" or "weekdays" (default).
`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.
`sort`	No	Sort the names: "last" (by last name), "first" (alphabetical) or leave out to keep the order given.
`dates`	No	Session dates for the column headings, e.g. ["2026-11-02", "2026-11-04"] or "Nov 2, Nov 4, Nov 6". Or use start_date with end_date, weeks, sessions or month.
`month`	No	A whole month of meeting days, e.g. "November 2026".
`names`	No	Student or member names, pasted as one name per line, comma separated text or a list, e.g. "Ava Brown\nLiam Chen\nNoah Diaz" or ["Ava Brown", "Liam Chen"]. "Last, First" names stay whole when one per line. Leave out for blank name rows.
`pages`	No	Number of identical blank pages when no list is given, 1 to 50, e.g. 3. Default 1.
`title`	No	Class or group name printed as the heading, e.g. "Period 3 Biology". Default "Attendance Sheet".
`weeks`	No	Number of weeks from start_date, e.g. 4.
`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	Teacher or instructor printed in the header, e.g. "Ms. Patel".
`end_date`	No	Last class date, e.g. "2026-12-18".
`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".
`sessions`	No	Number of sessions (date columns), e.g. 10. Without dates the columns are left blank to write dates in.
`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.
`start_date`	No	First class date, e.g. "2026-11-02". With end_date, weeks or sessions, dates are listed on the meeting days.
`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.
`instructions`	No	One line of instructions under the header, e.g. "Please print clearly". Each type has a default; "none" removes it.
`total_column`	No	Add a Total column at the end, e.g. false. Default true.
`extra_columns`	No	Columns to add to the defaults, e.g. "Dietary needs" or ["T-shirt size", "Initials"].

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 the safety profile (readOnly, idempotent, non-destructive) and an output schema exists, yet the description still adds genuine behavior: overflow handling ("Long rosters continue on more pages and too many dates split into column sets, with headings repeated") and dual deliverables (PDF plus CSV). It stops short of stating any size or time limits on generation.

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?

It is front-loaded with the usage trigger and sized sensibly for a 25-parameter tool. The first sentence is a long comma-and-parenthetical chain that is dense to parse, but no sentence is filler and the negative-scope line at the end earns its place.

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 zero-required-parameter generator with an output schema and full annotation coverage, the description supplies the essential picture: what gets produced, how dates and names are accepted, and how output grows across pages. The only substantive gap is sibling differentiation against generate_sign_in_sheet and generate_sign_up_sheet.

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 coverage is 100% across 25 parameters, so each field is already self-documenting with rich examples. The description adds only a high-level summary of the date-specification modes (explicit date list, start/end with meeting days, weeks, month, or blank columns), which is useful orientation but not meaning beyond the schema. Baseline 3 applies when the schema carries the detail.

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 names a specific verb and resource ("generate an attendance sheet or class roster template to print") and enumerates the concrete output shape: name rows, one column per session date or blank date columns, plus a Total column. It never mentions the sibling tools generate_sign_in_sheet and generate_sign_up_sheet, so an agent cannot use the text alone to decide between them.

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 an attendance sheet or class roster template to print" gives clear triggering context, and the closing line sets negative bounds (does not take attendance online, calculate grades or store records). What is missing is any reference to the two sibling generators, which is the one alternative an agent most needs to weigh.

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?