CoastWise MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| smoke_checkA | Health check for the CoastWise MCP server. Echoes a value back so a client can confirm the transport, tool listing, and input validation are all working. |
| get_beach_forecastA | 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. |
| rate_activity_conditionsA | Deterministic suitability rating for one beach, one date, and one activity. Returns a verdict, a 0-100 score normalized across the range attainable here, the per-Factor explanation, and any Veto that overrode the score. A missing required Factor yields insufficient_data rather than a guess. |
| find_best_activity_windowA | Slides a fixed 3-hour block across the requested window at hourly stride and names the most suitable stretch, scoring each block by the mean of its hours with the same rules as rate_activity_conditions. A candidate counts only when all three consecutive hours carry every required Factor; a gap disqualifies rather than bridges, and disqualified hours are reported under skippedHours instead of being ranked. Returns every evaluated candidate sorted by score, the hours that could not be evaluated and why, and best: null with a reason when no 3-hour stretch qualifies. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: health check, raw forecast retrieval, deterministic condition rating, and best-window search. The descriptions explicitly separate get_beach_forecast from rate_activity_conditions, reducing misselection risk.
All tools use consistent snake_case with predictable verb_noun or verb_phrase structure: smoke_check, get_beach_forecast, rate_activity_conditions, find_best_activity_window. The pattern is easy to infer.
Four tools is compact but reasonable for a focused forecast-and-rating server. Each tool earns its place, though the surface is slightly thin compared with broader domain servers.
The core workflow is covered: health check, raw forecast, activity rating, and optimal time-window search. A discovery tool for available beaches or valid activity names would close a minor usability gap, but the main operations are present.