Skip to main content
Glama

Can you drink the tap water here?

tap_water
Read-onlyIdempotent

Whether the tap water is drinkable, hamlet by hamlet (17 hamlets), from the guide's read of the water utility's and the state health department's own reporting. Three of the hamlets covered (Springs, Shelter Island, Southold) are private-well territory where no agency tests the water, and the record says so. Wainscott's record covers PFOS and PFOA found in more than 150 private wells and the December 2018 main extension that put the hamlet on public water. Every safe value refers to public water only; the guide holds no verdict on any private well. verdict is the guide's own paragraph for that hamlet. status comes with statusMeaning. filterRecommendation names a certification rather than a brand, with filterCaveat where the guide's glossary has corrected which NSF/ANSI number covers PFAS. sources are the citable links with the date each was read, including SCWA's June 2025 declaration of compliance with the federal PFOA/PFOS limits and the Stage 1 Water Alert declared across the East End on 14 July 2026, a drought conservation request whose own notice says supply and quality are unaffected. utilities names who pipes the water and a phone number, with no URL because the guide's filed links for those records no longer resolve. noVerdictHeld names a place the guide has not written up. place takes a hamlet, a region, or a ZIP. With no argument nothing is looked up and the answer lists the hamlets covered. 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
placeNoThe place: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'), in the asker's own words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / place / description
      Previous value: -"Where they are: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'). Pass the asker's own words."New value: +"The place: a hamlet ('Montauk', 'Springs', 'Wainscott'), a region ('the Hamptons', 'North Fork'), or a ZIP ('11937'), in the asker's own words."
  2. 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"
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-open-world, but the description adds substantive behavior beyond them: private wells are untested and carry no verdict, `safe` applies to public water only, `noVerdictHeld` flags unwritten places, `townScope.recognized: false` yields an empty rows array plus `didYouMean`, and `utilities` deliberately has no URL because filed links no longer resolve. The known-unknowns and failure-mode disclosure is unusually candid.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is one undifferentiated block that drifts from dataset provenance into output-field narration, sources, utilities, and error semantics. Since there is no output schema, much of that content does earn its place, yet backtick-delineated field explanations buried mid-paragraph are slower to parse than a short structured layout would be.

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 a single optional parameter, the description carries the full explanatory load and does so: it names the return fields (`verdict`, `status`/`statusMeaning`, `filterRecommendation`/`filterCaveat`, `sources`, `utilities`, `noVerdictHeld`, `townScope`) and explains the placeholder/empty-result conditions. An agent has everything it needs to call this correctly and to interpret the reply.

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 100% and the single `place` description already lists hamlet/region/ZIP, so the schema does most of the work. The description nonetheless adds meaning the schema lacks: how the argument is interpreted is echoed back in `townScope`, and a miss produces an empty result set rather than an error, which changes how the agent should phrase and retry the call.

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?

Opening clause states a specific question-resource pair: 'Whether the tap water is drinkable, hamlet by hamlet (17 hamlets), from the guide's read of the water utility's and the state health department's own reporting.' Scope (17 hamlets), provenance, and the unit of granularity are all pinned down, and the tool is clearly distinguishable from the generic directory-style siblings.

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?

It tells the agent what argument forms are accepted (hamlet, region, ZIP) and explicitly covers the zero-argument case: 'With no argument nothing is looked up and the answer lists the hamlets covered.' That is real invocation guidance, though it never names an alternative sibling or states when *not* to reach for this tool.

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