Skip to main content
Glama
Sign In

Gillby

by io.github.OneWave-AI
OverviewDiscussionsAdmin

Dated fishing catches and occurrences

get_fishing_records
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_records"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
+}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds meaningful behavior beyond that: a 26-hour staleness threshold, last-good time semantics for partial outages, state-isolated publications, bounded OBIS/iNaturalist for California, and 'no upstream downloads on tool calls'. This is genuine added context, though return/pagination behavior is only mentioned in passing.

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

Conciseness3/5

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

Purpose is front-loaded, but the description is an undifferentiated block of dense jargon mixing parameter semantics, freshness rules, canonical-view instructions and caveats. The units sentence ('ft, kt, s, F, mi') looks like boilerplate that adds little to a fishing-records tool, and the prescriptive 'preserve…' sentences could be tightened.

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 single nested object with eleven undocumented sub-parameters and no output schema, the description supplies most of what an agent needs: defaults, date semantics, weighting behavior, source caveats and a note that it returns data plus source/freshness metadata. Remaining gaps (bbox format, pagination via limit/offset, catchesOnly filter) are the main omissions.

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 description coverage the description carries the full burden, and it documents the important nested fields: from/to as inclusive YYYY-MM-DD observation dates, month pooling all selected years, state selecting separate publications, species belonging to the state, weighting (recent = 365-day half-life, historical = equal weights), and cellDegrees values. It leaves bbox, limit, offset and catchesOnly undocumented, so it compensates well but not completely.

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 first sentence names a specific resource — dated NOAA commercial catches and research/community occurrences for Florida and California — so an agent knows it returns evidence records rather than forecasts. However, it does not explicitly distinguish itself from close siblings like get_fishing_heatmap or get_fishing_insights, and its talk of heatmap cells and density bleeds into that territory.

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 through strong exclusions ('not live fish locations, migration tracks, abundance, catch rates') which steer interpretation but not tool selection. There is no explicit 'use this when… instead of X' routing to the many fishing/aquatic siblings, so the agent must infer when this is the right call.

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

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

Resources