Gillby

Conditions for any water lat/lon (dropped pin)

get_point_conditions

Read-onlyIdempotent

Same bundle as get_conditions for an arbitrary point inside Florida coverage, including the Keys and Everglades. Model cache points round to 0.02 deg; station references are used only near configured spots. Hosted cold pins request worker publication and return 503 with Retry-After while pending; retry the same coordinate. Source times and coverage remain explicit. Returns 422 unprocessable when the point is on land (details.nearestSpot suggests a spot). Cold point processing can take longer than a named-spot read. Rate limited. Start here for a current spot question with view=summary: this single result includes forecast, tides, scores, advisories, hazards, lightning and source status. Avoid duplicate hazard/tide calls unless a needed detail is absent. For beach questions, sea-model wave heights and NWS breaking-surf heights measure different things; their difference alone is not a forecast conflict. A swim no-go must not be followed by a recommendation to wade. Interpretation: omit boat unless the user supplied or confirmed it. Describe lightning as flashes observed or not detected in the stated window, never a clear/safe guarantee. Report unavailable/QC-failed sources even when freshness.stale=false; fresh does not mean every source is usable. Model sea height is not breaking surf height. Tide heights at different local MLLW gauges do not establish relative channel depths. High tide is not necessarily slack current. For kitesurfing use get_conditions with kiteStyle (freeride/waves/foil), kiteExperience and rider-supplied kiteMinWindKt/kiteMaxWindKt. Read kiteboarding for weather screening, gust spread and explicitly unverified launch status. Never infer the rider wind range, legal launch access or rescue coverage. Activity keys: kite, surf, skim (flatland), skim-wave (wave riding), paddle (flatwater paddleboard), sup-surf (SUP surf). Skim suitability is unscored without shoreline observations; missing scores must not inherit another activity. Offshore wind can favor surf while increasing paddleboard drift risk. A point depth cannot prove route clearance. Do not invent detection percentages, future readings, vessel ownership, or app settings instructions. Units: ft, kt, s, F, mi; directions FROM. Returns data and source/freshness metadata.

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": {
      "query": "<query>"
    },
    "name": "get_point_conditions"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 21, 2026
RemovedOct 21, 2026
AddedOct 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing cache rounding to 0.02 deg, station fallback only near configured spots, 503 + Retry-After for pending cold-pin publication, 422 with details.nearestSpot for land points, slower cold processing, and rate limiting. This is exactly the operational context readOnly/idempotent hints cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A ~350-word wall of text where behavioral facts, usage routing, interpretation guardrails ('A swim no-go must not be followed by a recommendation to wade'), and anti-hallucination rules compete. Front-loaded behavioral detail is good, but many sentences serve prompt-safety rather than tool selection and should not be in a description.

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?

Given the broad domain (forecast, tides, scores, advisories, hazards, lightning) and the absence of an output schema, the description covers error modes, caching, units (ft, kt, s, F, mi; directions FROM) and notes that data plus source/freshness metadata are returned. The actual payload structure is only hand-waved, which is the one remaining gap.

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?

Top-level schema coverage is 0%, so the description must compensate, and it does for view=summary, kiteStyle (freeride/waves/foil), kiteExperience and the rider-supplied kiteMinWindKt/kiteMaxWindKt constraint, plus the 'omit boat unless confirmed' rule. It leaves briefing and the full payload sizing partly unexplained.

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 names the resource (the same conditions bundle as get_conditions) and the scope that differentiates it (an arbitrary lat/lon inside Florida coverage, including the Keys and Everglades). An agent can immediately tell it apart from get_spot/get_conditions, which serve named spots.

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?

Explicitly says to start here for current spot questions with view=summary, warns against duplicating hazard/tide calls, and routes kitesurfing needs to get_conditions with kiteStyle/kiteExperience/rider wind range. When-to-use and when-not-to-use are both stated.

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

All Gillby 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.