Zovo Tide Tables

Find tide stations

find_tide_stations

Read-onlyIdempotent

Use this when the user names a US coastal place and needs the NOAA tide prediction station to use for a tide table. Takes a city or town (US places of about 15,000 people or more), a station name, or a NOAA station id, and returns the nearest stations with distance in miles. Does not return tide times; use generate_tide_calendar for those. Does not cover places outside the NOAA CO-OPS station list.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "place": "<place>"
    },
    "name": "find_tide_stations"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many stations to return, 1 to 10. Default 5, e.g. 5.
`place`	Yes	A US coastal city or town, a NOAA tide station name, or a NOAA station id. Add the state after a comma if you know it, e.g. Monterey, CA or Montauk or 9414290.
`state`	No	Optional two-letter US state or territory code to narrow the search, e.g. FL.

Output Schema

Name	Required	Description	Default
`note`	Yes
`query`	Yes
`state`	Yes
`source`	Yes
`stations`	Yes
`matched_city`	Yes
`name_matches`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the result format (nearest stations with distances) and the explicit negative behavior (no tide times) plus the station-list coverage limit. It stops short of describing what happens on a miss or how ranking handles near-ties, which keeps it from a 5.

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?

Three tightly packed sentences, front-loaded with the usage trigger, followed by input/output shape and then the two exclusions. Every clause carries routing or scoping information; nothing is redundant with the title.

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 an output schema present and full param coverage, the description only needs to supply routing and scope, which it does comprehensively, including the fallback sibling and the geographic/dataset boundary. No gap remains that would cause a wrong call.

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%, so the baseline is 3, but the description earns more by adding a constraint absent from the schema: US places of roughly 15,000 people or more, which tells the agent when a query is likely to fail. It also reinforces the three accepted place formats and distance output in a way that complements the per-parameter descriptions.

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 ('find' + 'NOAA tide prediction station') with explicit input types (city/town, station name, station id) and output shape ('nearest stations with distance in miles'). It cleanly separates itself from its only sibling by declaring it does not return tide times.

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?

Opens with an explicit trigger condition ('when the user names a US coastal place and needs the NOAA tide prediction station'), names the alternative tool for the adjacent need, and states the coverage boundary (outside the CO-OPS station list). An agent has everything needed to route correctly.

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

All Zovo Tide Tables 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?