Gillby

Fishing record-density heatmap cells

get_fishing_heatmap

Read-onlyIdempotent

Published state-isolated Florida and California fishing evidence (state defaults to florida; California default species california-halibut): dated NOAA commercial catches and research/community occurrences, source/license credits, coordinate uncertainty, seasonal record counts and configurable 0.25/0.10/0.05/0.02/0.01/0.005-degree heatmap cells. Historical records are not live fish locations, migration tracks, abundance, catch rates or catch probabilities. Sampling/fishing effort is uncorrected; absent records do not establish fish absence. from/to are inclusive YYYY-MM-DD observation dates; month pools all selected years. state selects separate publications; species must belong to that state. Publication checks older than 26 hours are stale; query last-good times preserve partial outage age. California uses bounded OBIS/iNaturalist occurrences, not a comprehensive catch survey. Source check time is not observation time. Recency weighting defaults to recent: exponential 365-day half-life based on observation dates, not source retrieval. weighting=historical gives equal weights. No upstream downloads on tool calls. Preserve species, observation dates, source credits, coordinate uncertainty, query coverage, partial/stale flags and fishing-effort bias. Heatmap color is record density, never fish abundance or catch odds. Commercial catches and occurrences must remain distinguishable. No generated migration paths. Units: ft, kt, s, F, mi; directions FROM. Returns data and source/freshness metadata.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_fishing_heatmap"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 20, 2026

removedInput schema / properties / query / properties / species / default
```
Removed value: -"mahi"
```

changedInput schema / properties / query / properties / species / enum

Previous value: -[
-  "mahi",
-  "blue-marlin",
-  "white-marlin",
-  "tarpon",
-  "snook"
-]New value: +[
+  "mahi",
+  "blue-marlin",
+  "white-marlin",
+  "tarpon",
+  "snook",
+  "california-halibut",
+  "kelp-bass",
+  "pacific-yellowtail",
+  "lingcod"
+]

addedInput schema / properties / query / properties / state

Added value: +{
+  "default": "florida",
+  "enum": [
+    "florida",
+    "california"
+  ],
+  "type": "string"
+}

AddedOct 19, 2026

TDQS

A3.5/5.0

Behavior5/5

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

Beyond the annotations (readOnly/idempotent/openWorld/non-destructive), it discloses substantial behavior: a 26-hour staleness threshold, that no upstream downloads occur on tool calls, the default recency weighting with a 365-day half-life vs equal historical weights, uncorrected sampling effort, and partial/stale flag semantics.

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 dense run-on wall of text that opens with provenance rather than stating what is returned, and back-loads 'Returns data and source/freshness metadata' to the very end. Many caveats are defensible, but the front-loading and sentence economy are poor.

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

Completeness3/5

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

For a complex nested-parameter tool with no output schema, it covers provenance, bias caveats, staleness and weighting well, but leaves bbox/limit/offset/catchesOnly unexplained and says little about the shape of the returned cells. Adequate but with visible gaps given the tool's complexity.

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?

With 0% schema coverage the description must carry the load, and it adds real meaning for the key fields: from/to date format and inclusivity, month pooling across years, state/species pairing rules, weighting semantics, and the cellDegrees options. It omits bbox, limit, offset, catchesOnly, and the wrapping query object, so coverage is strong but incomplete.

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 makes clear this returns state-scoped fishing record-density heatmap cells built from NOAA commercial catches plus research/community occurrences, at configurable cell sizes. The purpose is legible but not stated as a clean verb+resource and no sibling (e.g. get_fishing_records, get_fishing_insights) is named to disambiguate.

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

Usage Guidelines2/5

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

It gives operational constraints (state selects separate publications, species must belong to that state, from/to are inclusive) but never says when to reach for this tool versus get_fishing_records or get_fishing_insights, and offers no exclusions or alternatives. The heavy 'what this is not' text is interpretation guidance, not usage routing.

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.