Skip to main content
Glama
kykoay

BC Water Tides MCP Server

by kykoay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

BC Water Tides MCP Server

A Model Context Protocol (MCP) server that provides access to Canadian tide predictions from the Integrated Water Level System (IWLS) API. This server enables AI applications to retrieve tide forecasts for monitoring stations across Canada.

Features

Tools

  • get_tide_forecast - Get 7-day tide height predictions for a specific station

  • list_stations - List available tide monitoring stations with filtering options

Related MCP server: HK Climate and Weather MCP Server

Installation

  1. Clone or download this repository

    git clone <repository-url>
cd bc-tide-mcp-server

  2. Install dependencies

    pip install -r requirements.txt
# or using uv
uv sync

Usage

Running the Server

Development mode (stdio):

python main.py

Using uv:

uv run main.py

Integration with Claude Desktop

Add to your Claude Desktop configuration file (claude_desktop_config.json):

{
  "mcpServers": {
    "bc-tides": {
      "command": "python",
      "args": ["/absolute/path/to/bc-tide-mcp-server/main.py"]
    }
  }
}

Or using uv:

{
  "mcpServers": {
    "bc-tides": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/bc-tide-mcp-server", "main.py"]
    }
  }
}

API Reference

Tools

get_tide_forecast

Get 7-day tide height forecast for a Canadian monitoring station.

Parameters:

  • station_name (required): The name of the monitoring station (e.g., "Point Atkinson", "Vancouver", "Victoria"). Partial matching is supported.

Returns:

{
  "success": true,
  "station": {
    "name": "Point Atkinson",
    "id": "5cebf1de3d0f4a073c4bbcef",
    "code": "07795",
    "latitude": 49.3299,
    "longitude": -123.2633,
    "operating": true
  },
  "time_range": {
    "from": "2024-01-01T00:00:00Z",
    "to": "2024-01-08T00:00:00Z"
  },
  "resolution": "SIXTY_MINUTES (hourly)",
  "total_predictions": 168,
  "forecasts": [
    {
      "timestamp": "2024-01-01T00:00:00Z",
      "water_level_meters": 3.42,
      "qc_flag": "2"
    }
  ]
}

list_stations

List available tide monitoring stations.

Parameters:

  • search_term (optional): Filter stations by name

  • operating_only (optional, default: true): Only return currently operating stations

  • limit (optional, default: 20): Maximum number of stations to return (1-100)

Returns:

{
  "success": true,
  "search_term": "vancouver",
  "operating_only": true,
  "total_matching": 3,
  "stations": [
    {
      "name": "Point Atkinson",
      "alternative_name": null,
      "id": "5cebf1de3d0f4a073c4bbcef",
      "code": "07795",
      "latitude": 49.3299,
      "longitude": -123.2633,
      "operating": true
    }
  ]
}

Example Station Names

  • Point Atkinson (near Vancouver)

  • Victoria

  • Tofino

  • Prince Rupert

  • Nanaimo

  • Campbell River

Data Source

This server uses the Integrated Water Level System (IWLS) API provided by Fisheries and Oceans Canada (DFO-MPO).

API Base URL: https://api-iwls.dfo-mpo.gc.ca/api/v1

Example Usage in Claude

After setting up the server, you can use it in Claude Desktop:

"What are the tide predictions for Point Atkinson for the next week?"

"List all tide stations near Victoria"

"Get the tide forecast for Tofino"

License

This project is licensed under the MIT License.

Available Tools

4 tools
get_tide_forecastA

Get 7-day tide height forecast for a Canadian monitoring station.

This tool retrieves predicted water levels for the next 7 days from the Integrated Water Level System (IWLS) API. Data is returned at hourly intervals.

The tool first searches for the station by name (partial match supported), then retrieves the tide predictions starting from midnight UTC today.

Returns:

  • Station information (name, ID, coordinates)

  • List of hourly tide predictions with timestamps and water levels (in meters)

Examples of station names:

  • "Point Atkinson" (near Vancouver)

  • "Victoria"

  • "Tofino"

  • "Prince Rupert"

ParametersJSON Schema
NameRequiredDescriptionDefault
station_nameYesThe name of the monitoring station (e.g., 'Point Atkinson', 'Vancouver', 'Victoria'). Partial matching is supported.

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses hourly intervals, UTC start time, partial-match search, and the structure of returned data (station info and predictions). It does not mention error handling or rate limits, but for a read-only forecast tool this is adequate.

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 moderately detailed but well-structured with a clear opening, a behavior explanation, and a return section. It is front-loaded with the primary purpose and avoids excessive fluff, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description covers the essential context: time range, timezone, data frequency, station selection, and return format. It lacks details on error handling or station-not-found behavior, but overall is sufficiently complete for an agent to call it correctly.

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?

The schema already describes station_name, but the description adds value by explicitly noting partial matching support and providing concrete examples like 'Point Atkinson' and 'Victoria'. This goes beyond the schema's basic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves 7-day tide height forecasts for a Canadian monitoring station, with a specific verb and resource. It is distinguishable from list_stations and plot_tide_forecast, but does not explicitly differentiate from the sibling get_tide_forecast_pst, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for retrieving tide forecasts but provides no explicit guidance on when to choose this tool over alternatives like get_tide_forecast_pst (which likely differs by timezone). It gives examples of station names but lacks when-not-to-use instructions.

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

get_tide_forecast_pstA

Get tide height forecast with timestamps converted to Pacific Standard Time (PST/PDT).

This tool retrieves predicted water levels and converts all timestamps from UTC to Pacific Time (America/Vancouver timezone), automatically handling PST/PDT transitions.

Use this tool when you need tide data displayed in local BC time rather than UTC.

Returns:

  • Station information (name, ID, coordinates)

  • List of hourly tide predictions with PST timestamps and water levels (in meters)

  • High and low tide information for the requested period

Examples of station names:

  • "Point Atkinson" (near Vancouver)

  • "Campbell River"

  • "Victoria"

  • "Tofino"

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoOptional specific date to filter results (format: YYYY-MM-DD). If provided, only returns data for that date in PST. Leave empty to get all 7 days.
station_nameYesThe name of the monitoring station (e.g., 'Point Atkinson', 'Vancouver', 'Victoria'). Partial matching is supported.

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses UTC-to-Pacific conversion, automatic PST/PDT handling, and the returned content (station info, hourly predictions, high/low tides). It does not mention any edge cases or error behavior, but for a read-only forecast tool this is reasonably transparent.

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 description is well-structured with a usage line, return list, and examples, but the first two sentences are largely redundant: both state that the tool retrieves tide forecasts and converts timestamps to Pacific Time. Some trimming would make it tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description covers the essential context: timezone behavior, return contents, station examples, and the usage condition. It does not describe the full response shape, but the bullet list gives sufficient orientation for an agent to call it correctly.

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%, so the baseline is 3. The description adds a few station-name examples beyond the schema, including Campbell River and Tofino, but it largely repeats what the input schema already provides and adds no deeper meaning about the parameters.

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 action and resource: retrieving tide height forecasts and converting timestamps to PST/PDT. It clearly differentiates this tool from the likely UTC-based sibling by emphasizing local BC time and the America/Vancouver timezone.

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 explicitly says to use this tool when tide data is needed in local BC time rather than UTC. It does not name the sibling alternative or state when not to use it, but the intended context is clear and actionable.

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

list_stationsA

List available tide monitoring stations.

This tool retrieves a list of monitoring stations from the IWLS API. You can filter by name and operating status.

Useful for discovering station names before using the get_tide_forecast tool.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of stations to return (1-100).
search_termNoOptional search term to filter stations by name. Leave empty to list all stations.
operating_onlyNoIf true, only return currently operating stations.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool retrieves data from the IWLS API and can filter by name and operating status, which is useful. However, it doesn't disclose details like pagination behavior, default limit, or whether the list is sorted. The description is adequate but not rich in behavioral context.

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 concise and well-structured. It opens with a clear one-line summary, then provides a brief elaboration and a usage hint. Every sentence earns its place, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no required parameters and full schema coverage, the description is largely complete. It explains the purpose, the data source, and the use case. The only minor gap is the lack of detail about the return format, but since there is no output schema and the tool is a simple list, this is a minor omission.

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 description coverage is 100%, so the schema already documents all three parameters (limit, search_term, operating_only) with descriptions. The description adds minimal parameter meaning beyond the schema, only mentioning 'filter by name and operating status' which maps to search_term and operating_only. Baseline 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool's function: 'List available tide monitoring stations' and 'retrieves a list of monitoring stations from the IWLS API.' It also mentions filtering by name and operating status, which distinguishes it from the sibling forecast tools. The verb 'list' and resource 'stations' are specific and unambiguous.

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?

The description explicitly says the tool is 'Useful for discovering station names before using the get_tide_forecast tool,' which provides clear context for when to use it. It doesn't explicitly state when not to use it or name alternatives, but the sibling tools are clearly different (forecast vs. list), so the usage context is reasonably clear.

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

plot_tide_forecastA

Generate a tide height plot showing water levels as a function of time in PST.

This tool creates a visual chart of tide heights throughout a specified day, with timestamps displayed in Pacific Standard Time (PST/PDT).

The plot includes:

  • Tide height curve with hourly data points

  • Highlighted high and low tide markers with annotations

  • Optimal diving zone indicator (low tide window)

  • Dark, ocean-themed styling

Returns:

  • Plot image (either saved to file or as base64 data)

  • High and low tide summary information

Use this tool when the user wants a visual representation of tide patterns for dive planning, fishing, boating, or other marine activities.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesThe specific date to plot (format: YYYY-MM-DD). The plot will show tide heights for this entire day in PST.
titleNoOptional custom title for the plot. If not provided, uses default title with station name and date.
save_pathNoOptional file path to save the plot image. If not provided, returns base64-encoded image data.
station_nameYesThe name of the monitoring station (e.g., 'Point Atkinson', 'Campbell River', 'Victoria'). Partial matching is supported.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the behavioral burden and does so thoroughly: it discloses the PST/PDT timezone, hourly data points, high/low markers, diving-zone indicator, output modes (file or base64), and returned high/low summary. It also implies no destructive side effects beyond optional file saving.

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 well structured with bullets and front-loaded purpose, but the first two sentences are somewhat redundant: both state that it produces a tide-height chart over a day in PST/PDT. Minor repetition prevents a perfect score.

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?

For a medium-complexity tool with no output schema, the description covers the return value (plot image and summary), save behavior, timezone, plot contents, and appropriate use cases. The agent has enough context to invoke it correctly and interpret its result.

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 description coverage is 100%, so the schema already documents date, title, save_path, and station_name well. The description adds only generic context about 'the specified day' and 'optional' fields without explaining parameter behavior beyond the schema.

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 opening sentence uses a specific verb ('Generate') and resource ('tide height plot'), and the description clearly distinguishes this from the sibling data-retrieval tools by emphasizing visual output. The plot's contents and styling make its purpose unambiguous.

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?

The final sentence gives concrete context for when to use the tool ('visual representation... for dive planning, fishing, boating'). It does not explicitly contrast with get_tide_forecast or get_tide_forecast_pst for cases where tabular data is needed instead of a plot.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedget_tide_forecast
    • First observedget_tide_forecast_pst
    • First observedlist_stations
    • First observedplot_tide_forecast
Deploy Server
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

TDQS

A4.1/5.0

Scored across 4 tools

Disambiguation4/5

Most tools are clearly distinct: list_stations for discovery, plot_tide_forecast for visualization. get_tide_forecast and get_tide_forecast_pst overlap heavily as the same forecast data, but their descriptions explicitly differentiate UTC vs PST output, reducing confusion.

Naming Consistency4/5

Tools follow a consistent verb_noun pattern (list_stations, get_tide_forecast, plot_tide_forecast). get_tide_forecast_pst introduces a timezone suffix modifier, which is a minor deviation but still predictable and readable.

Tool Count5/5

Four tools is well-scoped for a tide forecast server: station discovery, UTC forecast data, PST-localized forecast data, and visualization. Each tool serves a distinct need without redundancy or bloat.

Completeness4/5

The core workflow is covered: discover stations, retrieve forecast data, localize it, and visualize it. Minor gaps exist, such as no option to specify a custom date range or fetch real-time observed water levels, but these are not core to the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Surf MCP Server

    ravinahp
    A
    license
    B
    quality
    D
    maintenance
    Fetches tide information for any location using latitude and longitude, providing detailed tide data including high/low tides and station information with automatic UTC time zone handling.
    1
    19
    MIT

  • tideline

    Earththing
    F
    license
    Not graded
    quality
    B
    maintenance
    MCP server that provides tide predictions, station lookup, and tidal event alerts for US coastal locations using live NOAA data.
    -

  • mcp-tides

    pipeworx-io
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides NOAA tide predictions and observed water levels, allowing AI agents to query tide stations and current water level data.
    2 npm
    MIT