Zovo Tide Tables

Generate tide calendar

generate_tide_calendar

Read-onlyIdempotent

Use this when the user wants a tide table, tide calendar or tide times for a NOAA station for a month or up to 31 days: high and low times and heights (MLLW, ft or m, local time), sunrise and sunset, an optional low-tide filter, a printable PDF calendar (Letter and A4), CSV and ICS calendar files. Data is NOAA CO-OPS predictions (fetched from NOAA, cached up to 24 hours), not observations. Needs a NOAA station id (get one from find_tide_stations). Does not give currents, surf, weather or observed water levels.

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": {
      "station_id": "<station_id>"
    },
    "name": "generate_tide_calendar"
  }
}

Input Schema

Name	Required	Description
`month`	No	Calendar month as YYYY-MM, e.g. 2026-12. Use this or start_date and end_date.
`units`	No	Height units: ft (default) or m, e.g. ft.
`end_date`	No	Last day as YYYY-MM-DD (inclusive), e.g. 2027-01-05.
`start_date`	No	First day as YYYY-MM-DD, e.g. 2026-12-20. Needs end_date; at most 31 days in total.
`station_id`	Yes	NOAA tide station id from find_tide_stations: 7 digits, or 3 letters and 4 digits for some subordinate stations, e.g. 9414290 or TPT2799.
`low_tide_filter`	No	Optional: highlight low tides that fit a plan such as tide pooling or clamming, e.g. {"max_height":0,"daylight_only":true}.

Output Schema

Name	Required	Description	Default
`days`	Yes
`note`	Yes
`datum`	Yes
`units`	Yes
`filter`	Yes
`period`	Yes
`source`	Yes
`station`	Yes
`summary`	Yes
`windows`	Yes
`downloads`	Yes
`days_shown`	Yes
`time_zones`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful context beyond them: the data is NOAA CO-OPS predictions rather than observations, it is fetched and cached up to 24 hours, and several output formats are supported. It also states negative capabilities, which helps prevent misuse.

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 description is front-loaded with the primary use case and contains no obvious filler. The first sentence is dense and carries many clauses, so it could be split for readability, but every detail included is relevant to correct tool selection and invocation.

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?

Given the rich schema, output schema, annotations, and nested filter object, the description is complete enough for an agent to decide when and how to call the tool. It covers prerequisites, output formats, date scoping, data source, and exclusions.

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 description coverage is 100%, so parameter meanings are already well documented. The description still adds useful semantics by mentioning MLLW, local time, the 31-day limit, and the practical purpose of the optional low-tide filter for activities like tide pooling or clamming.

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 states a specific verb and resource: generating a tide table or calendar for a NOAA station. It clearly scopes the output to high/low times and heights, sunrise/sunset, and PDF/CSV/ICS files, and distinguishes itself from find_tide_stations by explaining that station IDs come from the sibling tool.

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?

It explicitly says when to use the tool: when the user wants a tide table, calendar, or tide times for a NOAA station for a month or up to 31 days. It names the prerequisite station lookup via find_tide_stations and explicitly excludes currents, surf, weather, and observed water levels.

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?