mcp

Beach water quality

get_beach_water_quality

Read-onlyIdempotent

Puerto Rico beach water quality: which beaches are under a no-swimming advisory, and the latest Enterococcus bacteria count at each of the ~49 beaches the island monitors under the federal BEACH Act. Returns the beaches named in DRNA's current notice with their town and the days the water was sampled, every station's latest count with its sample date and a verdict, how often each beach has been flagged across the notices on record, and the separate volunteer-lab samples (Surfrider Rincón, Arrecifes Pro Ciudad). IMPORTANT — the verdict vocabulary is exactly three states and NEVER the word 'safe': 'advisory' (not suitable for swimming), 'within' (the count was at or under the 70 colonies/100 mL Beach Action Value), and 'stale' (no sample in 21 days — the source's own latest value for a station can be YEARS old, so it is not a verdict either way; check verdict.sampledOn before believing any number). Only DRNA's notice can place a beach under advisory (verdict.basis 'notice'); a count above 70 that no notice covers is reported as verdict.basis 'reading'. Results are published days after sampling and water changes with rain and tide, so never state or imply that a beach is currently safe to swim — report the number, the date, and the advisory state. Cite 787daily.com/live/beaches/.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_beach_water_quality"
  }
}

Input Schema

Name	Required	Description	Default
`beach`	No	Optional beach name, station id (e.g. RW-19) or town to filter to. Omit for the whole island.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / beach / description

Previous value: -"Optional beach name, station id (e.g. RW-19) or municipio to filter to. Omit for the whole island."New value: +"Optional beach name, station id (e.g. RW-19) or town to filter to. Omit for the whole island."

First observedOct 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it defines the exact three-state verdict vocabulary, warns that the source's latest value for a station can be YEARS old and must be checked against verdict.sampledOn, and explains that only a DRNA notice can place a beach under advisory while a bare reading above 70 is verdict.basis 'reading'. It also discloses publication latency (days after sampling) and environmental volatility.

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?

Front-loaded with purpose and the advisory framing, and the dense middle section is justified because the verdict vocabulary and staleness warning are essential to correct interpretation. It is long and reads as one dense block, but nearly every clause earns its place.

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 return-value burden and does so thoroughly: it enumerates the notice beaches with town and sample days, every station's latest count with sample date and verdict, flag frequency across notices, and the separate volunteer-lab samples. It also supplies a citation requirement, leaving nothing material unstated.

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 coverage is 100% and the single optional 'beach' parameter is fully documented in the schema (name, station id like RW-19, or town). The description adds no format or filtering detail beyond what the schema already states, so the baseline 3 is correct.

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 and resource (Puerto Rico beach water quality — advisories and Enterococcus counts at ~49 monitored beaches) and scopes it to the federal BEACH Act monitoring program. This is immediately distinguishable from siblings like get_water_status (reservoir/drinking water) and get_trail_conditions.

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 clear context for use and strong operational constraints: report the number, the date and the advisory state, and never state or imply a beach is currently safe. However, it never explicitly names an alternative tool or an exclusion condition, so the 'when not to use / use instead' routing is left implicit.

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

All mcp tools Inspect

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

Need Help?