Skip to main content
Glama

Generate sign-in sheet

generate_sign_in_sheet
Read-onlyIdempotent

Use this when the user wants a sign in sheet template, a visitor log template, a contact or email sign-up sheet, or a weekly sign-in and out timesheet to print for a meeting, event, class, open house or front desk. Returns a print-ready PDF where the rows fill each page to the bottom margin and the column headings repeat on each page, plus a CSV template. Custom columns, title, date, organization, row count, Letter/A4/Legal, landscape, striping. Does not collect sign-ins online, track hours or calculate pay. For volunteer or potluck sign-ups use generate_sign_up_sheet; for class rosters with dates use generate_attendance_sheet.

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

Input Schema

NameRequiredDescriptionDefault
dateNoDate 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.
daysNoTimesheet only: which days, e.g. "Mon-Fri" (default), "Mon, Wed, Fri" or "every day".
rowsNoNumber 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.
pagesNoNumber of identical blank pages when no list is given, 1 to 50, e.g. 3. Default 1.
titleNoHeading printed at the top, e.g. "Board Meeting Sign-In" or "Fall Open House". Default depends on the sheet type.
columnsNoColumn 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).
teacherNoHost or supervisor name printed in the header, e.g. "Dana Ruiz".
locationNoLocation printed in the header, e.g. "Room 204" or "Community Hall". Leave out for a blank line.
numberedNoPrint a # column with row numbers, e.g. true. Default true for sign-in, contact and attendance sheets.
org_nameNoOrganization, school or business name printed above the title, e.g. "Maple Street PTA".
stripingNoLight gray shading on alternate rows (or alternate groups), e.g. false for plain rows. Default true.
subtitleNoOptional second line under the title, e.g. "Quarterly review, 6 pm".
page_sizeNoPaper size: "Letter" (default, 8.5x11), "A4" or "Legal". "A4 landscape" also sets the orientation.
sheet_typeNoWhich sheet, e.g. "sign-in" (meeting, event, class or open house; default), "visitor log" (date, visitor name, company, host, time in, time out, badge #, signature), "contact" (name, email, phone, company, OK to email) or "timesheet" (weekly sign-in and out by day).
week_startNoTimesheet only: first day of the week, e.g. "2026-11-02". Rows are grouped by day with dates.
orientationNo"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.
instructionsNoOne line of instructions under the header, e.g. "Please print clearly". Each type has a default; "none" removes it.
extra_columnsNoColumns to add to the defaults, e.g. "Dietary needs" or ["T-shirt size", "Initials"].
spots_per_dayNoTimesheet only: name rows under each day, e.g. 6. Default fills the page.

Output Schema

NameRequiredDescriptionDefault
labelYes
notesYes
pagesYes
titleYes
groupsYes
assumedYes
columnsYes
downloadsYes
page_sizeYes
blank_rowsYes
sheet_typeYes
total_rowsYes
names_countYes
orientationYes
print_checkYes
date_columnsYes
row_height_inYes
rows_per_pageYes
prefilled_rowsYes
links_expire_minutesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, but the description still adds meaningful context: it returns a print-ready PDF plus CSV, rows fill each page to the bottom margin, headings repeat across pages, and online collection/tracking/pay calculation are out of scope. The behavioral profile is clear and consistent with the annotations.

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

Conciseness5/5

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

The description is three dense sentences with no filler. It front-loads the use cases, then outputs and customization, then exclusions and sibling alternatives, which matches how an agent needs to decide and act.

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?

Given the tool's complexity (19 optional parameters), the rich schema, and the presence of an output schema, the description covers everything needed for selection and invocation: purpose, output artifacts, layout behavior, exclusions, and alternatives. No critical context 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 description coverage is 100% and each parameter already has rich examples, defaults, and edge-case notes. The description adds little parameter-level meaning beyond listing custom columns, title, date, organization, row count, paper sizes, landscape, and striping, so it largely repeats what the schema documents.

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 uses a specific verb and resource ("generate sign-in sheet") and immediately enumerates concrete variants: visitor log template, contact/email sign-up sheet, and weekly sign-in/out timesheet. It explicitly distinguishes this tool from generate_sign_up_sheet and generate_attendance_sheet, so an agent can select it without opening sibling schemas.

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 gives explicit when-to-use context across meetings, events, classes, open houses, and front desks, then states what the tool does not do (collect sign-ins online, track hours, calculate pay) and names the exact alternative tools for volunteer/potluck sign-ups and dated class rosters. This is strong routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources