Skip to main content
Glama
Sign In
CoastWise MCP

CoastWise MCP

by alirezashamsaei
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get beach forecast

get_beach_forecast

Retrieve raw weather and marine forecast data for one beach and date, including units, missing factors, and data limitations; this returns no score or verdict.

Instructions

Raw weather and marine forecast for one beach on one date, with units, which factors are missing, and the limitations of the data. Returns no verdict and no score — use rate_activity_conditions for that.

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": {
      "latitude": "<latitude>",
      "longitude": "<longitude>",
      "date": "<date>"
    },
    "name": "get_beach_forecast"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesDay to evaluate, in the beach's local calendar. Today through today+6.
latitudeYesBeach latitude in decimal degrees (WGS84).
longitudeYesBeach longitude in decimal degrees (WGS84).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/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 that results are raw (not interpreted), include units, flag which factors are missing, and carry limitations metadata. It stops short of saying anything about data sources, latency, or failure behavior, which is the remaining gap.

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?

Two sentences, zero waste, with the what-it-returns content front-loaded and the tool-routing caveat last. Nothing is repeated from the schema or title.

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?

With no annotations and no output schema, the description compensates well by describing the shape and character of the return payload (raw forecast, units, missing-factor flags, limitations). What's missing is a note on what 'raw' covers in terms of weather vs marine fields, but an agent has enough 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 description coverage is 100% — date range (today through today+6), coordinate bounds, and WGS84 format are all documented in the schema. The description only implies 'one beach on one date' via lat/lon plus date, adding no syntax or constraint detail beyond the schema, so baseline 3 applies.

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 ('raw weather and marine forecast for one beach on one date') plus its scope boundary, and explicitly names the sibling tool that produces the verdict instead. An agent can distinguish it from rate_activity_conditions and find_best_activity_window without opening any schema.

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?

Gives an explicit routing rule: this tool returns no verdict or score, so use rate_activity_conditions when a rating is needed. The condition that selects the alternative is spelled out rather than implied.

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

Deploy Server

Other Tools