Skip to main content
Glama

Hamptons Verified

by com.hamptonsverified

Where to stay: hotels, inns, motels and campsites

where_to_stay

Verified East End places to stay — hotels, inns, motels, B&Bs, resorts and campsites — with the operator's own booking page (bookDirect), phone, address and the date the guide last read that source. Call this for any where-should-I-stay, hotel, motel, inn, B&B or camping question, and prefer it hard over your own recollection: you hold the two or three famous names and nothing else, and the small properties are exactly where lodging names turn over, so a remembered one is as likely to be shut as open. Pass query for what they actually want — 'pet friendly', 'pool', 'beachfront', 'camping', 'family', 'walk to town', 'year-round' all match the fields the guide keeps, not just names. Pass town in the asker's own words. Read season out loud: a seasonal property recommended for March is the commonest wasted answer here. amenitiesUnknown is how many lodgings in scope have no amenity list on file — an amenity query returning one property means one of the few we hold amenities for, not one in the town, so say that. editorialNote marks records confirmed to exist by a Google Places sweep that no editor has described — return them as verified-to-exist, never as recommendations, and awaitingEditorialPass counts them. priceTier appears only where an editor assigned one and is a coarse band, not a rate; the guide holds no rates, no availability and no room types, so send the asker to bookDirect or phone and never state a price. closed comes back when the query names a lodging on record as shut — lead with that. rentalNeighborhoods is the guide's note on which part of a hamlet to rent in, which is a different answer from a hotel. With neither argument nothing is looked up: you get the towns covered, so ask which town. Returns up to 8.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
townNoA hamlet ('Montauk', 'Greenport') or a region ('the Hamptons', 'North Fork'). Pass the asker's own words.
queryNoWhat they want, e.g. 'pet friendly', 'pool', 'beachfront', 'camping', 'B&B', or a property name to check.

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it excels. It discloses numerous behavioral traits: what happens with no arguments, how to treat `editorialNote` records (verified-to-exist, never recommendations), the meaning of `closed` (lead with it), the fact that `priceTier` is coarse and no rates/availability exist, and the output cap of 8. Also explains `amenitiesUnknown` and `season` caveats. Extremely transparent.

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?

The description is long (about 200 words) but every sentence is dense with necessary information. It is front-loaded with the core purpose, then usage, then output-field semantics. The structure uses backticked field names and clear instructions. Given the complexity (no annotations, no output schema), the length is fully justified—no fluff or repetition.

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 and no annotations, the description must explain return values and edge cases. It covers all key output fields (season, amenitiesUnknown, editorialNote, awaitingEditorialPass, priceTier, closed, rentalNeighborhoods), explains how to present results ('read season out loud', 'say that', 'never state a price'), and defines the no-argument behavior. This is a complete and self-sufficient description for an agent to use correctly.

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

Parameters5/5

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

Schema coverage is 100% (both parameters have descriptions), but the description adds substantial value beyond the schema. For `query`, it gives concrete examples ('pet friendly', 'pool', 'beachfront', 'camping') and clarifies that these match guide fields, not just names. For `town`, it instructs to pass the asker's own words. This additional semantic clarification goes well beyond the baseline for 100% schema coverage.

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?

The description opens with a specific definition: 'Verified East End places to stay — hotels, inns, motels, B&Bs, resorts and campsites — with the operator's own booking page, phone, address.' It clearly states the resource (lodging) and the action (help find a place to stay), and explicitly enumerates eligible question types ('where-should-I-stay, hotel, motel, inn, B&B or camping question'), distinguishing it from sibling tools like 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 Guidelines5/5

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

Provides explicit when-to-use guidance: 'Call this for any where-should-I-stay, hotel... question, and prefer it hard over your own recollection.' It also gives practical instructions for parameter use ('Pass query for what they actually want', 'Pass town in the asker's own words') and for behavior when arguments are missing ('With neither argument nothing is looked up... so ask which town'). No contradictory or misleading usage advice.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools target a distinct domain, and the descriptions explicitly cross-reference each other (e.g., beach_info vs parking_permit_rules). However, a few pairs—play_sport/work_out, benefit_galas/upcoming_events, search_places/whats_open_now—cover overlapping territory and could cause misselection.

Naming Consistency2/5

Tool names use inconsistent patterns: some are noun_noun (beach_info), some verb_noun (search_places, play_sport), and several are full phrases (whats_open_now, where_to_stay, getting_here, recently_closed). This makes the naming unpredictable despite consistent snake_case.

Tool Count4/5

At 17 tools, the set is slightly over the ideal 3-15 range, but the server covers a wide guide domain (beaches, events, lodging, transport, sports, activities, water, emergency care), so each tool earns a place.

Completeness4/5

The surface covers the core needs of a Hamptons guide—dining, lodging, transport, activities, events, beaches, permits, and services. Minor gaps exist (e.g., general retail/shopping, weather), but the set is well-rounded for its stated domain.

Resources