Skip to main content
Glama

Aisle

by wedding.aisle
OverviewDiscussionsAdmin

Wedding Alcohol Calculator

get_alcohol_estimate
Read-onlyIdempotent

Estimates wedding bar quantities from guest count, event duration and drink mix, with bottles and cases rounded up. Quantities follow planning rules of thumb and are not a guarantee of consumption. This tool does not purchase alcohol.

Input Schema

NameRequiredDescriptionDefault
mixNoBar mix across wine, beer, and spirits (default: balanced)
crowdNoHow much the crowd drinks (default: average)
hoursNoHours of open bar (default: 5)
guest_countNoTotal number of wedding guests
non_drinkersNoGuests in guest_count who will not drink alcohol (default: 0). The bar and the toast are sized for the rest.
champagne_toastNoWhether the estimate includes one flute of champagne per guest for a toast. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / non_drinkers
      Added value: +{
+  "description": "Guests in guest_count who will not drink alcohol (default: 0). The bar and the toast are sized for the rest.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
  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 readOnly, idempotent and non-destructive behavior. The description adds context beyond them: bottles and cases are rounded up, quantities are rules-of-thumb rather than a consumption guarantee, and the tool does not actually purchase alcohol. That is meaningful boundary-setting for an estimating tool.

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 tight sentences, front-loaded with the core capability, followed by the rounding behavior and then the non-purchase disclaimer. No filler.

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?

No output schema exists, yet the description sufficiently conveys the return shape (bottles and cases, rounded up) and the non-guarantee caveat. Only a fuller statement of the returned fields/pagination would push this higher, and for a simple planning estimator this is close to complete.

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 every parameter including enums and defaults is already documented; baseline is 3. The description names guest count, duration and drink mix but adds no syntax or defaults 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 (estimates), a specific resource (wedding bar quantities), and the inputs that drive it (guest count, duration, drink mix). An agent can distinguish this from get_budget_estimate or get_cash_gift_suggestion 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 Guidelines3/5

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

The description implies when it applies (planning bar quantities for a wedding) but offers no explicit when-not guidance and does not reference any alternative tool. Usage is inferable but not spelled out.

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