Reception layouts to scale, seating charts, wedding day timelines, and budgets. No login needed.
Scored across 4 tools
Each tool has a clearly distinct purpose: timeline generation, budget estimation, named seating assignment, and reception floor planning. The seating-chart and layout tools explicitly cross-reference each other to prevent misselection between assignments and floor plans.
All four names follow a consistent snake_case verb_noun pattern: build_wedding_timeline, estimate_wedding_budget, generate_seating_chart, plan_reception_layout. The minor extra 'wedding' in two names does not break the convention.
Four tools is well-scoped for a focused wedding-planning assistant, with each tool covering a major planning output. There is no obvious filler or redundant tool in the set.
The set covers key planning calculations but lacks obvious wedding-planning operations such as checklist management, vendor/payment tracking, RSVP tracking, and venue search. These gaps are acknowledged in the descriptions, which helps agents avoid dead ends but still leaves the surface incomplete for a broad wedding planner.
Use this when someone wants a minute-by-minute wedding day schedule: getting ready, first look, ceremony, cocktail hour, reception, send-off. Needs the ceremony start time; everything else has defaults. Do not use for the months-long planning checklist or vendor payment schedules.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | City and state, for sunset. | |
| send_off | No | none | |
| first_look | No | ||
| same_venue | No | ||
| wedding_date | No | YYYY-MM-DD, for sunset. | |
| ceremony_time | Yes | Ceremony start, 24-hour HH:MM. | |
| travel_minutes | No | ||
| reception_hours | No | ||
| ceremony_minutes | No | ||
| photo_priorities | No | ||
| cocktail_hour_minutes | No | ||
| hair_and_makeup_people | No |
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| warnings | Yes | |
| share_url | No | View-only link to this timeline. |
| sunset_time | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by disclosing that only the ceremony start time is required and everything else falls back to defaults, which is essential for minimal-input invocation. Annotations already communicate that this is a non-destructive, non-idempotent generator, so no contradiction, though side effects of generation are not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the use case, followed by the minimum input requirement and a concise exclusion. Nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, and the description covers selection and the minimal-input contract well. The main gap is parameter semantics for the eleven undocumented optional fields, which is a moderate but not fatal omission for a default-heavy generator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 12 parameters and only 25% schema description coverage, the description should compensate more, but it only identifies ceremony_time as the sole required input. It never explains that location/wedding_date drive sunset calculation, what the enums mean, or the ranges on duration parameters, leaving most of the schema undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('minute-by-minute wedding day schedule') and enumerates the phases it covers, so the agent knows exactly what it produces. It does not explicitly contrast with the actual sibling tools (budget, seating, layout), though the resource difference is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use trigger ('when someone wants a minute-by-minute wedding day schedule') plus an explicit when-not clause excluding planning checklists and vendor payment schedules. The alternatives named aren't the sibling tools, so the routing guidance is slightly indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone gives a total wedding budget, a guest count, or both and wants a category-by-category split (venue, catering, photo and video, flowers, music, attire, stationery, and so on) with per-guest math and a contingency line. Do not use for tracking actual spending or vendor payments.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | classic | |
| region | No | national | |
| priorities | No | ||
| guest_count | No | ||
| total_budget_usd | No |
| Name | Required | Description |
|---|---|---|
| share_url | No | View-only link to this budget. |
| categories | Yes | |
| assumptions | Yes | |
| guest_count | Yes | |
| per_guest_usd | Yes | |
| contingency_usd | Yes | |
| total_budget_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real context beyond the annotations by describing the shape of the result (per-guest math, contingency line) and the scope boundary. However, with readOnlyHint=false declared, an agent could reasonably wonder whether the estimate is persisted or creates state; the description never says it is a pure calculation that writes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the trigger condition and closed with a clean exclusion. The parenthetical category list is slightly long but it doubles as a preview of the output, so it earns most of its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values needn't be explained since an output schema exists, and the two headline inputs are covered. But a 5-parameter, zero-required, zero-description schema with region/style/priority modifiers leaves the agent guessing how those knobs change the estimate — the description should close that gap and doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only implicitly covers two of five parameters (budget by 'total wedding budget', guest count by 'guest count'). It never explains style, region, or — most importantly — how the `priorities` list (max 3) reweights the split, which is the parameter most likely to be misused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (estimate/split) and resource (wedding budget) plus the concrete output shape: category-by-category split, per-guest math, contingency line. The enumerated categories and the explicit exclusion of spending tracking make it unmistakable against the timeline/seating/layout siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when someone gives a total wedding budget, a guest count, or both') and an explicit anti-pattern ('Do not use for tracking actual spending or vendor payments'). It stops short of naming an alternative tool for that excluded case, so it's strong but not a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone has a list of wedding guests and wants them assigned to tables, keeping families, friend groups, or couples together and keeping specific people apart. Accepts names with optional group labels and keep-apart pairs. Returns table assignments and a shareable chart. Do not use for floor plans without names (use plan_reception_layout) or for RSVP tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | ||
| keep_apart | No | Pairs of names to seat at different tables. | |
| table_count | No | ||
| fill_strategy | No | balanced | |
| keep_together | No | ||
| seats_per_table | No | ||
| head_table_names | No |
| Name | Required | Description |
|---|---|---|
| tables | Yes | |
| unseated | Yes | |
| warnings | Yes | |
| share_url | No | View-only link to this chart. |
| truncated | No | True when names or tables were cut to stay under 50 KB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is non-readonly, non-destructive, closed-world, and non-idempotent. The description adds useful behavioral context about keeping groups together, separating specified people, and returning table assignments plus a shareable chart, though it does not clarify persistence or side effects of generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tight sentences, front-loading purpose and usage before alternatives. Every sentence carries useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, usage, and output nature, and an output schema exists, but the low schema description coverage means the description should do more to explain the optional seating parameters. It is adequate but incomplete for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low, so the description must compensate. It mentions names, optional group labels, and keep-apart pairs, but omits key parameters such as table_count, seats_per_table, fill_strategy, keep_together, and head_table_names, leaving most optional inputs unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 seating chart" for wedding guests) and clearly states the core grouping constraints. It also distinguishes this from floor-plan layout and RSVP tracking tools, so an agent can identify it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it (guest list needing table assignments) and when not to use it, naming plan_reception_layout for floor plans and excluding RSVP tracking. This is strong routing guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to plan a wedding reception floor plan, figure out how many tables fit in a room, or check whether a venue space can hold their guest count with a dance floor, bar, buffet, DJ or band, and head table. Needs guest count; room dimensions in feet are optional (if missing, returns the space required instead of a fit check). Do not use for ceremony seating, seating assignments by name (use generate_seating_chart), or venue search.
| Name | Required | Description | Default |
|---|---|---|---|
| bars | No | ||
| cake_table | No | ||
| head_table | No | sweetheart | |
| dance_floor | No | ||
| guest_count | Yes | Total guests, including the couple. | |
| table_shape | No | round_60 | |
| food_service | No | plated | |
| entertainment | No | dj | |
| room_width_ft | No | Room width in feet. | |
| room_length_ft | No | Room length in feet. | |
| seats_per_table | No | Defaults by shape: round_60 8, round_72 10, rectangle_8ft 10, mixed 8. |
| Name | Required | Description |
|---|---|---|
| fits | Yes | |
| notes | Yes | |
| zones | Yes | Corner positions in feet from the entrance corner; x along the length, y across the width. |
| tables | Yes | Table center positions in feet, same axes as zones. |
| room_ft | Yes | The room the positions are drawn in, in feet. |
| share_url | No | View-only link to this plan. |
| truncated | No | True when table positions were dropped to stay under 50 KB. |
| seats_needed | Yes | One seat per guest. |
| tables_needed | Yes | |
| seats_available | Yes | |
| tables_that_fit | Yes | Tables placed in the room; fewer than tables_needed when the room is too small. |
| slack_square_feet | Yes | |
| suggested_room_ft | Yes | |
| square_feet_needed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuinely non-obvious behavior beyond the annotations: when room dimensions are omitted the tool returns required space instead of a fit check — a different response mode that changes how the agent should interpret output. It also flags guest_count as mandatory while dimensions are not. The annotations (readOnlyHint=false, idempotentHint=false) are conservative for what is effectively a calculation tool, but the description does not contradict them outright, it simply under-describes persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the trigger phrase, keeps the exclusion clause last, and every sentence carries routing or behavioral information. The mid-sentence element list ('dance floor, bar, buffet, DJ or band, and head table') is slightly enumerative but usefully signals what the space calculation accounts for.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description still covers the dual output modes and the required precondition. For an 11-parameter tool it leans on defaults and enums to fill gaps, but nothing critical for a correct first call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, so the description carries extra weight, and it does explain the required/optional split and the conditional output for the two room-dimension parameters. However, the eight other parameters — table_shape, seats_per_table, food_service, entertainment, bars, cake_table, head_table — get their meaning only from enum values and defaults in the schema, not from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb-plus-resource with three distinct capabilities (floor plan, table-count fitting, capacity check) and enumerates the elements it accounts for (dance floor, bar, buffet, DJ/band, head table). It also explicitly excludes ceremony seating and venue search, so an agent can separate it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit 'use this when' trigger, then a 'do not use for' clause that names a sibling (generate_seating_chart) as the alternative for name-based seating assignments. It also states the one precondition (guest count required) versus the optional room dimensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
plan_reception_layout3 fields changedOutput schema / properties / seats_neededAdded value: +{
+ "description": "One seat per guest.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / tables_that_fitAdded value: +{
+ "description": "Tables placed in the room; fewer than tables_needed when the room is too small.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / requiredPrevious value: -[
- "tables_needed",
- "seats_available",
- "square_feet_needed",
- "fits",
- "slack_square_feet",
- "suggested_room_ft",
- "room_ft",
- "zones",
- "tables",
- "notes"
-]New value: +[
+ "tables_needed",
+ "seats_needed",
+ "tables_that_fit",
+ "seats_available",
+ "square_feet_needed",
+ "fits",
+ "slack_square_feet",
+ "suggested_room_ft",
+ "room_ft",
+ "zones",
+ "tables",
+ "notes"
+]build_wedding_timelineestimate_wedding_budgetgenerate_seating_chartplan_reception_layoutParty budgets, headcount quantities, timelines and checklists. Free.
Find wedding venues and vendors, estimate costs, and manage guests, events and wedding details.
Anonymous, no-login wedding planning: create a project, add guests, auto-generate a seating plan.
Run your wedding from Claude or ChatGPT: guests, RSVPs, meals, seating and your wedding site.
Add one secure layer between your agents and this server.
