Skip to main content
Glama

Benefit galas: the dates, the dress code, and who the money goes to

benefit_galas
Read-onlyIdempotent

The East End's summer benefit season: 15 dated charity galas, each joined to the nonprofit it raises for. Call this for any gala, benefit, fundraiser, charity, black-tie, what-should-I-wear, where-can-I-donate or where-can-I-volunteer question. Three things here are unknowable from your weights. First the DATES: this is the 2026 season, and a benefit invented for the right-sounding weekend sends someone to an empty field. Second dressCode, which is the organiser's own and is the thing people actually ask — it is 'Cocktail' on 16 of the 15 and 'Black Tie' on exactly ONE, so the black-tie assumption you would reach for is wrong twenty-six times out of twenty-seven; 'Beach Formal', 'Farm Festive' and 'Garden Chic' are real answers you cannot guess. Third, the PRICE, which cuts both ways and is why you read tickets.publishedRate per record instead of generalising. On 14 of the 15 it is false, and that is a verified finding rather than a missing field — the organisers hand off to a ticketing platform and print no rate, and a sweep of all 15 ticket links found 11 dead and several resolving to a prior year. For those, NEVER state or estimate a price; say it is not published and give the phone. On 1 it is true, and tickets.published carries the organiser's own figure with the URL an editor read it from and the date — quote and cite that, keeping the word 'from', because it is the entry rate in a ladder and not the only price on sale. tickets.tier is a relative band across these events, not a figure, and nothing may be inferred from it either way. Where tickets.publishedTiers appears an editor read a real published line: quote it verbatim, including the ones whose content is that no price is published and here is the number — that IS the answer to what it costs. beneficiary carries the charity's mission, phone, donateUrl and volunteerUrl, all verified more recently than the ticket link, so give the phone as the route that works and answer 'I can't make it, can I still help' without leaving the data. alsoThisSeason holds the marquee fixtures with no gala record — the Hampton Classic, Authors Night, the art fair — and is where several more genuinely published prices in this vertical live. Past benefits never appear unless you pass from. Returns up to 10.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoISO date. Omit for the rest of the season.
fromNoISO date. Default is today (East End local), so only benefits still to come are returned. Pass an earlier date to reach ones already held.
townNoA hamlet ('East Hampton', 'Sag Harbor') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words.
causeNoFilter to one cause, when the question is plainly about one.
queryNoWhat they are after, e.g. 'animal', 'ARF', 'black tie', 'film', 'land trust', or a benefit's name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Far exceeds the annotations (readOnly/idempotent/destructive/openWorld), disclosing data-quality findings the agent could not infer: publishedRate false on 14 of 15 and why that is a verified finding rather than a missing field, 11 dead ticket links, the instruction never to state or estimate a price, and the rule to quote 'from' verbatim. This is the kind of behaviour-shaping context the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly 300 words for a five-parameter lookup tool, and the density is undercut by internal inconsistencies: 'Cocktail' on '16 of the 15' and a 'twenty-six times out of twenty-seven' ratio that matches no stated event count. Those conflations force re-reading and undermine an otherwise well-front-loaded opener.

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?

With no output schema, the description carries the full burden and does so: it explains dressCode, tickets.publishedRate/published/publishedTiers/tier, beneficiary (mission, phone, donateUrl, volunteerUrl), and alsoThisSeason. An agent can answer price, dress and donation questions without opening the payload.

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 the schema already documents all five parameters with formats and defaults. The description adds only marginal parameter-level nuance (query terms like 'ARF' and 'black tie', the from/to semantics), which mostly restates the schema, so the 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?

Opens with a concrete verb-and-resource statement: 'The East End's summer benefit season: 15 dated charity galas, each joined to the nonprofit it raises for.' It also enumerates the exact question types it answers, which separates it cleanly from siblings like upcoming_events or things_to_do.

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 strong positive routing ('Call this for any gala, benefit, fundraiser, charity, black-tie, what-should-I-wear ...') and one real conditional rule ('Past benefits never appear unless you pass `from`'). It does not name an alternative sibling or state a when-not-to-use case, so it stops short of a 5.

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