CoastWise MCP

Rate activity conditions

rate_activity_conditions

Rate beach conditions for a selected date and activity to get a deterministic verdict, 0–100 score, factor explanations, and vetoes; missing data returns insufficient_data.

Instructions

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.

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>",
      "activity": "<activity>"
    },
    "name": "rate_activity_conditions"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Day to evaluate, in the beach's local calendar. Today through today+6.
`window`	No	Local time window to evaluate, e.g. {"start":"09:00","end":"13:00"}. Omitted → 07:00–19:00.
`activity`	Yes	What the person plans to do.
`latitude`	Yes	Beach latitude in decimal degrees (WGS84).
`longitude`	Yes	Beach longitude in decimal degrees (WGS84).
`skillLevel`	No	Surfer experience. Required when activity is "surfing"; ignored for beach_day.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A3.7/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 substantial work: it discloses determinism, the return contents (verdict, normalized 0-100 score, per-Factor explanation, Veto), and the failure mode (insufficient_data rather than a guess). What it omits is operational context such as whether the underlying data is cached or rate-limited and what 'normalized across the range attainable here' means numerically, but nothing is contradicted.

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?

Three tight sentences, front-loaded with the core purpose and ending on the failure contract rather than burying it. Slight deduction because capital-F 'Factor' and capital-V 'Veto' are introduced as domain terms without definition, and 'normalized across the range attainable here' is vague on first read.

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 six-parameter tool with a nested window object, two enums, and no output schema, the description covers return shape and the insufficient_data case, which is what an agent most needs. The window's effect on the score and how a Veto interacts with the numeric score could be spelled out, but the profile is largely complete.

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%, including the conditional skillLevel rule and the window default, so the schema does the parameter work. The description only restates the one-beach/one-date/one-activity shape and adds no format, unit, or edge-case detail beyond it. Baseline 3 applies.

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 states a specific verb and resource ('Deterministic suitability rating') and pins the scope to 'one beach, one date, and one activity', which separates it from the bulk-forecast sibling get_beach_forecast and from find_best_activity_window. It stops short of naming any sibling explicitly, so differentiation is inferred from scope rather than stated.

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?

Usage is implied by the singular scope: rate one activity at one beach on one date. There is no explicit when-to-use guidance, no pointer to find_best_activity_window as the alternative when the user hasn't fixed a date or activity, and no stated prerequisites. An agent can infer fit, but must reason about routing itself.

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

Deploy Server