Skip to main content
Glama

Aisle

by wedding.aisle
OverviewDiscussionsAdmin

List My Wedding Guests

list_my_guests
Read-onlyIdempotent

Lists guests in the selected wedding who are recorded as 13 or older, with saved names, contact preferences (a "defaulted" list names any nobody chose), language, RSVP status and timestamps. Optional filters narrow results by RSVP status, language or name, and results can be ordered by name or by most recent update, RSVP reply or addition; per-status counts cover every listed guest before filtering. Guests under 13 or with unconfirmed ages are excluded, as are guest notes and dietary details. Requires sign-in.

Input Schema

NameRequiredDescriptionDefault
sortNoOrder of the guests. "name" (the default) is last name then first. "recently_updated", "recently_responded" and "recently_added" put the newest first, by updatedAt, rsvpRespondedAt and createdAt; guests with no time sort last, by name.
searchNoSearch guests by name. A first name, a last name, or the whole name all match, and accents are ignored, so Ines finds Inês.
languageNoFilter by a language name or code, such as Spanish or es. Empty string selects guests with no recorded language. Supported languages: English (en), Spanish (es), French (fr), Italian (it), German (de), Portuguese (pt), Polish (pl).
wedding_idNoIdentifier of a wedding the signed-in account can manage. Required when the account has multiple weddings.
rsvp_statusNoFilter by RSVP status, one status or a list such as ["pending", "maybe"] for everyone yet to confirm.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "Order of the guests. \"name\" (the default) is last name then first. \"recently_updated\", \"recently_responded\" and \"recently_added\" put the newest first, by updatedAt, rsvpRespondedAt and createdAt; guests with no time sort last, by name.",
+  "enum": [
+    "name",
+    "recently_updated",
+    "recently_responded",
+    "recently_added"
+  ],
+  "type": "string"
+}
  2. Changed5 schema fields changed
    • addedInput schema / properties / rsvp_status / anyOf
      Added value: +[
+  {
+    "enum": [
+      "pending",
+      "attending",
+      "declined",
+      "maybe"
+    ],
+    "type": "string"
+  },
+  {
+    "items": {
+      "enum": [
+        "pending",
+        "attending",
+        "declined",
+        "maybe"
+      ],
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array"
+  }
+]
    • changedInput schema / properties / rsvp_status / description
      Previous value: -"Filter by RSVP status"New value: +"Filter by RSVP status, one status or a list such as [\"pending\", \"maybe\"] for everyone yet to confirm."
    • removedInput schema / properties / rsvp_status / enum
      Removed value: -[
-  "pending",
-  "attending",
-  "declined",
-  "maybe"
-]
    • removedInput schema / properties / rsvp_status / type
      Removed value: -"string"
    • changedInput schema / properties / search / description
      Previous value: -"Search guests by name. A first name, a last name, or the whole name all match."New value: +"Search guests by name. A first name, a last name, or the whole name all match, and accents are ignored, so Ines finds Inês."
  3. Changed1 schema field changed
    • changedInput schema / properties / language / description
      Previous value: -"Filter by a language name or code, such as Spanish or es. Empty string selects guests with no recorded language."New value: +"Filter by a language name or code, such as Spanish or es. Empty string selects guests with no recorded language. Supported languages: English (en), Spanish (es), French (fr), Italian (it), German (de), Portuguese (pt), Polish (pl)."
  4. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
+  "description": "Filter by a language name or code, such as Spanish or es. Empty string selects guests with no recorded language.",
+  "type": "string"
+}
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, so the description is free to add the non-obvious behavior it does: guests under 13 and unconfirmed ages are excluded, notes and dietary details are omitted, and per-status counts span all listed guests before filtering. It does not mention pagination or result limits, which is the remaining gap.

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?

Front-loaded with the verb and scope, then the returned fields, then filters/sorting, then exclusions. Two dense sentences with no filler, though the second sentence carries a lot of stacked clauses and could be split for scanability.

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?

With no output schema, the description usefully compensates by naming the returned fields, the exclusion rules and the auth requirement. It is nearly complete for a list tool, missing only pagination/limit behavior and an explicit tie-break to sibling list/get tools.

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%, so each of the five parameters is already fully documented with enum values, sort semantics and search behavior. The description restates the filter dimensions at a high level but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 and resource ('Lists guests in the selected wedding') plus a precise scope constraint (recorded as 13 or older). It also enumerates the returned fields and the supported filters/sorts, so an agent can distinguish it from get_my_guest and list_my_events 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.

Usage Guidelines4/5

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

Gives clear usage context: optional filters narrow by RSVP status, language or name, and results can be ordered four ways. It also states the prerequisite ('Requires sign-in') and the eligibility boundary. It stops short of explicitly naming a sibling alternative or a when-not-to-use case, so it is not a 5.

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