Skip to main content
Glama
Sign In

Hamptons Verified

by com.hamptonsverified
OverviewDiscussionsAdmin

Plan a rules-checked East End day

plan_my_day
Read-onlyIdempotent

Three distinct, ordered East End day plans built by Hamptons Verified's deterministic planner, the same rules engine as the website. Each plan is a time-ordered list of stops with time, block, name, town, reason, source, the guide's own listing url, and a mapsUrl directions link. Before a plan is returned the planner applies permanent closures, the selected date's opening hours, age fit, budget, weather, daylight, geographic sequencing and the maximum drive between consecutive stops. A stop that is a dated event carries an event object: its time is the organiser's published start, with access, accessNote, ticketing, source, sourceUrl and lastVerified. eventsOnThisDateNotInThePlan lists events the guide holds for that date and scope that were not used, each with whyNotInThePlan. saved_places is a preference lane: names supplied by the asker are worked in where eligible and never override a closure, hours, travel or safety rule; the tool has no access to any account, browser or saved list. The answer reports vibesUnderstood, vibesNotUnderstood, whoReadAs and partySize, and a stop whose operator publishes a maximum party size below party_size carries a capacityWarning quoting the operator's line. townScope reports how the place argument was read; townScope.recognized: false means the name matched no East End place, the rows array is empty, and didYouMean lists near matches where any exist.

Input Schema

NameRequiredDescriptionDefault
whoNoWho the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value: a group of friends is `friends`, a group with children is `family`, and common aliases are resolved to the nearest value, which the answer reports in `whoReadAs`. Group size is `party_size`.
dateNoISO date (YYYY-MM-DD) in East End local time; defaults to today.
seedNoOptional stable seed; the same seed and inputs reproduce the same plans.
townNoA hamlet or region to keep the day around. Omit for the full East End.
vibesNoComma-separated interests from: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Values outside this list do not influence the plan and are reported in `vibesNotUnderstood`.
budgetNo
energyNo
party_sizeNoNumber of people, as digits. Stops whose operator publishes a maximum below this number carry a `capacityWarning` quoting the operator's line. When omitted, no capacity check is made.
saved_placesNoComma-separated venue names the asker wants included, used as preferences only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / date / description
      Previous value: -"ISO date in East End local time; defaults to today."New value: +"ISO date (YYYY-MM-DD) in East End local time; defaults to today."
    • changedInput schema / properties / party_size / description
      Previous value: -"How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line, several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed."New value: +"Number of people, as digits. Stops whose operator publishes a maximum below this number carry a `capacityWarning` quoting the operator's line. When omitted, no capacity check is made."
    • changedInput schema / properties / saved_places / description
      Previous value: -"Comma-separated saved venue names supplied by the asker. Never infer private account data."New value: +"Comma-separated venue names the asker wants included, used as preferences only."
    • changedInput schema / properties / seed / description
      Previous value: -"Optional stable seed when the asker wants the same result repeated."New value: +"Optional stable seed; the same seed and inputs reproduce the same plans."
    • changedInput schema / properties / vibes / description
      Previous value: -"Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on, it is never silently dropped."New value: +"Comma-separated interests from: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Values outside this list do not influence the plan and are reported in `vibesNotUnderstood`."
    • changedInput schema / properties / who / description
      Previous value: -"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value, a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question."New value: +"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value: a group of friends is `friends`, a group with children is `family`, and common aliases are resolved to the nearest value, which the answer reports in `whoReadAs`. Group size is `party_size`."
  2. Changed3 schema fields changed
    • changedInput schema / properties / party_size / description
      Previous value: -"How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line — several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed."New value: +"How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line, several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed."
    • changedInput schema / properties / vibes / description
      Previous value: -"Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on — it is never silently dropped."New value: +"Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on, it is never silently dropped."
    • changedInput schema / properties / who / description
      Previous value: -"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value — a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question."New value: +"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value, a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question."
  3. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. Changed4 schema fields changed
    • addedInput schema / properties / party_size
      Added value: +{
+  "description": "How many people are coming, as a number. Stops whose operator publishes a maximum BELOW it come back with a `capacityWarning` quoting that operator's own line — several Sag Harbor charters cap at six. Omit when the asker did not say; nothing is guessed.",
+  "type": "string"
+}
    • changedInput schema / properties / vibes / description
      Previous value: -"Comma-separated interests such as quiet, foodie, cultural, beach, adventure, romantic, active, or off-season."New value: +"Comma-separated interests. The planner understands exactly these: quiet, active, foodie, cultural, beach, adventure, romantic, off-season, shopping, anything. Anything else is reported back in `vibesNotUnderstood` rather than acted on — it is never silently dropped."
    • addedInput schema / properties / who / description
      Added value: +"Who the day is for: solo, couple, family, friends, first-date, in-laws. There is no 'group' value — a group of friends is `friends` and a group with children is `family`; pass either and the answer reports which was used in `whoReadAs`. For the size of the group use `party_size`, which is a different question."
    • removedInput schema / properties / who / enum
      Removed value: -[
-  "solo",
-  "couple",
-  "family",
-  "friends",
-  "first-date",
-  "in-laws"
-]
  5. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent and non-destructive, but the description adds substantial behavior: the planner applies closures, hours, age, budget, weather, daylight, sequencing and drive limits before returning plans. It also discloses saved_places as preferences only with no account/browser access, and handles event objects, exclusions and unrecognized towns.

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?

The purpose is front-loaded and most sentences carry field-level or rule-level detail rather than filler. It is dense and one long block, with several output-field lists packed together, so structure could be clearer, but it is not repetitive.

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?

Because there is no output schema, the description appropriately explains plan row fields, event details, excluded events, saved-place handling, reported reading fields, capacity warnings and townScope failure behavior. For a 9-parameter planner this is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (78%), so the baseline is 3; the description still adds meaning for saved_places, party_size capacity warnings, townScope recognition and didYouMean behavior. Budget and energy are not elaborated beyond their enums, but the description compensates where it matters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by stating it builds three ordered East End day plans with a deterministic rules engine, so the verb and resource are unambiguous. It does not explicitly name sibling tools or contrast itself with search_places/things_to_do, so it falls short of full sibling differentiation.

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?

Use is implied by planning a day and by the mention of the same rules engine as the website, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the itinerary builder rather than a venue search.

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

All Hamptons Verified toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources