Skip to main content
Glama
Sign In

Gillby

by io.github.OneWave-AI
OverviewDiscussionsAdmin

Get checked parking guides

get_parking_guides
Read-onlyIdempotent

Discover checked Florida or California launch/trailer and beach parking guides. Supply state, optionally an exact guide ID; omit id to list available guides and IDs. Returns official sources, checkedAt (research date, not publication time), entrance directions when researched, permit/fee/access guidance, construction notices and published capacity where supplied. Coverage is selected locations, not every launch. Unknown IDs return no guide. availability is always null: no live occupancy, opening or reopening feed is connected. Never substitute ordinary car-lot parking for trailer permission. Facility inventory is available through get_poi_details for supported Florida POI IDs.

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

Input Schema

NameRequiredDescriptionDefault
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds rich context beyond them: checkedAt means research date not publication time, availability is always null with no live feed, unknown IDs return no guide, and results include source/freshness metadata.

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 and scope are front-loaded, and most sentences carry real information (checkedAt semantics, availability null, coverage limits). The trailing units/returns line is slightly boilerplate, but the overall density is justified for the amount of behavior disclosed.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so: it enumerates returned fields (official sources, checkedAt, directions, permit/fee/access, construction notices, capacity, availability null). Nothing essential for correct invocation is missing.

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?

Schema coverage is 0%, so the description must carry the load, and it does: state is required, id is optional and omitting it lists available guides and IDs, plus the Florida/California scope. It compensates well for the undocumented nested parameters, though it doesn't restate the id length bounds.

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 description opens with a specific verb+resource: 'Discover checked Florida or California launch/trailer and beach parking guides.' It scopes the resource precisely (launch/trailer and beach parking) and explicitly differentiates from the sibling get_poi_details for facility inventory, so an agent can route without opening schemas.

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

Usage Guidelines4/5

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

It gives concrete usage: supply state, optionally an exact guide ID, and omit id to list available guides. It also names an alternative (get_poi_details) for facility inventory and warns that coverage is selected locations, not every launch. Lacks an explicit 'when not to use' beyond that caveat, but context is clear.

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