Skip to main content
Glama

Aisle

by wedding.aisle
OverviewDiscussionsAdmin

Wedding Invitation Wording

get_invitation_wording
Read-onlyIdempotent

Composes wedding invitation text for a hosting situation and formality, using supplied names, event details and optional reception wording. With no scenario, it lists available options. Wording follows etiquette conventions rather than legal requirements.

Input Schema

NameRequiredDescriptionDefault
dateNoDate as it should read, e.g. "Saturday, the twelfth of June"
timeNoTime as it should read, e.g. "at four o’clock in the afternoon"
scenarioNoHosting-situation key. An absent value returns the available scenarios and formality options.
formalityNoRegister key: formal, modern, casual, or playful
host_namesNoHost names for scenarios that include hosts. Two hosting parties are separated by " / ".
venue_nameNoVenue name
hosts_childNoPartner whose parents are hosting. Defaults to couple_b for grooms-parents and couple_a for brides-parents or divorced-parents. Partner names never determine parentage.
couple_a_nameNoOne partner’s full name
couple_b_nameNoThe other partner’s full name
worship_spaceNoFormal register: is the ceremony in a house of worship?
reception_noteNoOptional final line, e.g. "Reception to follow"
venue_locationNoVenue town and country
child_relationshipNoRelationship word for the hosts’ child. Defaults to child for divorced-parents, daughter for brides-parents and son for grooms-parents.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / child_relationship
      Added value: +{
+  "description": "Relationship word for the hosts’ child. Defaults to child for divorced-parents, daughter for brides-parents and son for grooms-parents.",
+  "enum": [
+    "child",
+    "daughter",
+    "son"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / hosts_child
      Added value: +{
+  "description": "Partner whose parents are hosting. Defaults to couple_b for grooms-parents and couple_a for brides-parents or divorced-parents. Partner names never determine parentage.",
+  "enum": [
+    "couple_a",
+    "couple_b"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds two non-obvious traits: that it acts as a discovery endpoint when scenario is absent, and that wording follows etiquette conventions rather than legal requirements — a meaningful expectation-setting note about output nature.

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?

Three tightly packed sentences with zero filler: purpose first, then the no-scenario fallback, then the etiquette caveat. Each sentence carries distinct information and the most decision-relevant content is front-loaded.

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 13-parameter, zero-required, read-only generator with no output schema and full schema coverage, the description covers purpose, input intent, the discovery fallback, and output character. It could say more about the shape of the composed result, but annotations and the rich schema already cover safety and inputs, so the remaining gap is minor.

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% across all 13 parameters, including defaults and enum meanings, so the schema already carries the semantic load and baseline 3 applies. The description only loosely gestures at the parameter set ("supplied names, event details and optional reception wording") without adding syntax, format, or default-resolution detail beyond the schema.

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?

States a specific verb ("Composes") and resource ("wedding invitation text") with the inputs that drive it (hosting situation, formality, names, event details, reception wording). This clearly separates it from siblings like generate_wedding_hashtags or get_dress_code_guide, and the no-scenario fallback behavior is disclosed up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent what happens when scenario is omitted (it lists available options), which is genuinely useful call-time guidance for a generator. However, it never states when to reach for this tool versus alternatives, nor any prerequisites, so usage is only implied from the tool's purpose.

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

All Aisle toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources