Gillby

Fishing evidence and seasonal summaries

get_fishing_insights

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_insights"
  }
}

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.9/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly, openWorld, idempotent, non-destructive) by disclosing staleness rules (publication checks older than 26 hours are stale), partial-outage age handling, the absence of upstream downloads on calls, the exponential 365-day half-life recency weighting, and the crucial caveat that heatmap color is record density and never abundance or catch odds. That is exactly the behavioral context an agent needs and cannot get from structured fields.

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?

Purpose is front-loaded and the dense caveats (units, no live locations, sampling-effort bias) all earn their place, but the description is a very long, run-on block of warnings with some repetition and no structural separation between purpose, parameter semantics and caveats.

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 tool with no output schema, it supplies return guidance (data plus source/freshness metadata), units, defaults and staleness semantics, and the nested 11-property query object is at least partially explained. The remaining gap is sibling disambiguation against the other fishing tools.

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 0%, so the description carries the burden and it does cover several parameters well: state/species isolation, inclusive YYYY-MM-DD from/to, month pooling, weighting semantics (recent vs historical), and the cellDegrees heatmap resolution list. However, it leaves bbox format, limit, offset, the catchesOnly switch and the nested query wrapper entirely unexplained, so it only partially compensates.

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?

States a specific verb+resource: published state-isolated Florida/California fishing evidence, including dated NOAA commercial catches, research/community occurrences, source credits, seasonal counts and heatmap cells. Clear about what it returns, but it never distinguishes itself from the closely-named siblings get_fishing_heatmap and get_fishing_records, which is a real gap given the overlap in output.

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 only implied through defaults and constraints (state defaults to florida, California default species california-halibut, from/to are inclusive observation dates, month pools all selected years). There is no explicit statement of when to reach for this tool rather than get_fishing_heatmap, get_fishing_records or get_activity_scores, which an agent must infer.

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.