Skip to main content
Glama

Generate seating chart

generate_seating_chart

Use this when the user wants a seating chart or seating plan: a classroom seating chart for students (rows, pairs or groups of 4; keep two students apart; seat some students near the front; mixed groups; a new random seating chart each week that avoids last week's neighbours) or a wedding, party or banquet seating chart (round or long tables of N, keep couples and households together, keep two guests apart, head table, kids table). Accepts typed names or an uploaded roster or guest list (CSV/Excel). It checks each hard rule and reports any conflict, naming the rules that conflict. Returns the chart, a soft-preference score, and links to a printable PDF, place cards and Excel. Same seed gives the same chart; change seed to reshuffle. Each call saves new PDF and Excel files (which include the names) on the plugin server for 1 hour (private download links), then deletes them. Rosters are not saved. Does not seat stadiums, theaters or airplanes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mode": "<mode>"
    },
    "name": "generate_seating_chart"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYesclassroom for a teacher's seating chart of desks; event for a wedding, party, banquet or gala with tables.
rowsNoClassroom rows/pairs: number of rows from the front, e.g. 5.
seedNoShuffle number, e.g. 1 (default). The same inputs and seed give the same chart; use another number to reshuffle.
titleNoTitle printed on the chart, e.g. Period 3 - Room 114, or Lee & Park Wedding.
layoutNoClassroom desk layout: rows (single desks, default), pairs (desks in twos), or groups (pods/tables of group_size).
peopleNoThe students or guests: plain names ("Ava Martinez") or objects with flags, e.g. {"name":"Cara Diaz","needs_front_seat":true}. Leave out when a roster file is attached.
tablesNoEvents: table setup, e.g. [{"count":1,"seats":10,"type":"head","shape":"long"},{"count":12,"seats":8}].
columnsNoClassroom: desks per row (rows), desk pairs per row (pairs), or groups per row (groups), e.g. 6.
front_rowsNoClassroom: how many rows count as the front for needs_front_seat, e.g. 1 (default).
group_sizeNoClassroom groups layout: students per group, e.g. 4 (default).
keep_apartNoHard rule: people who must not sit next to each other (classroom: not beside, in front, behind or diagonal, nor in the same group; in pairs the seat across the aisle counts as beside unless aisle_breaks_adjacency is true; events: not at the same table). Each inner list is one rule, e.g. [["Ben","Eli"]].
label_ruleNoHow to use labels: mix (spread each label across groups and neighbours; the classroom default), group (seat the same label together, e.g. college friends; the event default), or ignore.
escort_sortNoEvents: sort the alphabetical escort card list by last_name (default) or first_name.
group_countNoClassroom groups layout: number of groups, e.g. 7. Default: just enough for everyone.
roster_fileNoOptional class roster or guest list as CSV, TSV or Excel .xlsx with a header row: a Name column (or First/Last), and optional Party/Household, Group/Label, Front seat, VIP, Child, RSVP, Keep apart (names) and Table columns, e.g. guests.xlsx.
table_countNoEvents shorthand: number of regular guest tables, e.g. 12. Default: just enough.
prefer_apartNoSoft preference: try to keep these people apart; scored, not forced. Each inner list is one rule, e.g. [["Uncle Joe","Aunt Sue"]].
keep_togetherNoHard rule: people who must sit next to each other (classroom) or at the same table (events). Each inner list is one rule, e.g. [["Ann Lee","Bob Lee"]].
prefer_togetherNoSoft preference: try to seat these people together; scored, not forced. Each inner list is one rule, e.g. [["Mia","Zoe"]].
seats_per_tableNoEvents shorthand: seats per regular table, e.g. 8 (default) or 10.
head_table_seatsNoEvents shorthand: add a long head table with this many seats for VIP guests, e.g. 10.
kids_table_seatsNoEvents shorthand: add a kids table with this many seats for guests marked child, e.g. 8.
previous_seat_orderNoClassroom rotation: last chart's seat_order from this tool (names by seat number, "" for empty desks). The new chart avoids last time's neighbours and desks.
aisle_breaks_adjacencyNoClassroom pairs: true if the aisle between desk pairs separates students, so the seat across the aisle does not count as beside. Default false (across the aisle counts as beside).

Output Schema

NameRequiredDescriptionDefault
modeYes
roomYes
seedYes
softYes
chartYes
seatsYes
titleYes
layoutYes
peopleYes
statusYes
warningsYes
conflictsYes
downloadsYes
hard_rulesYes
seat_orderNo
soft_scoreYes
chart_truncatedNo
seating_problemsYes
hard_rules_brokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations it discloses genuinely non-obvious behaviour: every hard rule is verified and conflicting rules are named in the report, the call always writes new PDF/Excel artifacts containing names to the plugin server, those files expire and are deleted after one hour behind private links, and rosters are never persisted. It also explains determinism ('Same seed gives the same chart; change seed to reshuffle'), which sharpens the non-idempotent annotation into an actionable statement.

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 trigger sentence and then packs the classroom and event cases into one dense but purposeful paragraph; the retention and determinism notes at the end are load-bearing. Some parenthetical enumerations of rules are lengthy, but none is filler.

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 24-parameter, nested-schema tool with an output schema and annotations, the description covers what is otherwise invisible: conflict reporting when rules clash, the returned artifacts and soft-preference score, determinism, and the one-hour server-side file lifecycle. Nothing an agent needs to decide whether and how to call this tool is absent, and return values are properly left to the output schema.

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?

With 100% schema description coverage the schema already explains seed, layout, tables, keep_apart and the shorthand parameters in detail, so the baseline is 3. The description adds a little framing (accepts typed names or an uploaded CSV/Excel roster; seed reshuffles) but no syntax, defaults or edge-case semantics the schema does not already carry.

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 opens with a specific verb and resource ('Use this when the user wants a seating chart or seating plan') and enumerates the two concrete domains: classroom desks and wedding/party/banquet tables. It never references the sibling tool check_seating_chart, so an agent still has to infer the division of labour between generating and checking a chart.

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?

It gives explicit when-to-use triggers with concrete examples ('keep two students apart', 'a new random seating chart each week') and a clear negative boundary ('Does not seat stadiums, theaters or airplanes'). What is missing is any routing to the alternative: check_seating_chart is never mentioned, so the generate-vs-verify choice is left implicit.

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