Skip to main content
Glama

commutescout

by io.github.nicglazkov
OverviewDiscussionsAdmin

get_chain_controls

Read-only

Current chain-control requirements on California mountain highways.

Data: Caltrans chain-control status for fixed checkpoints on mountain
routes (I-80 Donner, US-50 Echo Summit, SR-88, SR-89, and others).
Levels: R-1 = chains OR snow tires required; R-2 = chains required
except 4WD/AWD with snow tires on all four; R-3 = chains on ALL vehicles
(rare, usually precedes closure). Refresh: 5-minute cache.

Filters: route (e.g. "80", "US-50", "SR-88"); center "lat,lon" with
radius_km for all checkpoints around a place (e.g. around Truckee),
whatever highway they are on.

Off-season (roughly May-October) there are usually no controls anywhere;
the response says so explicitly rather than returning an empty list.
Chain requirements can change hour to hour in storms - tell the user the
data_as_of time and to carry chains anyway when snow is possible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
routeNo
centerNo
radius_kmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already provide readOnlyHint and openWorldHint. Description adds value beyond: 5-minute cache, response format (explicitly says if no controls), data_as_of time. No contradiction with annotations.

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

Conciseness5/5

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

Description is well-structured: summary, data details, levels, refresh, filters, seasonal behavior, advisory. No fluff, every sentence adds value. Front-loaded with main purpose.

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?

Given complexity (multiple routes, levels, filters, dynamic data), description covers all: what it returns, filter usage, caching, seasonal behavior. No output schema, but explicitly mentions response includes data_as_of time and explicit statement when no controls, which is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 3 params with 0% description coverage (only types). Description adds meaning: route examples ('80', 'US-50', 'SR-88'), center as 'lat,lon' with radius_km for filtering around a place. This fully compensates for lack of schema descriptions.

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 clearly states the tool retrieves current chain-control requirements on California mountain highways, listing specific routes and data source (Caltrans). It distinguishes from sibling tools like check_route and get_incidents by focusing on chain controls.

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?

Provides explicit guidance: explains filter usage (route, center, radius_km), seasonal behavior (off-season usually no controls, response says so), and warns about hour-to-hour changes, advising to check data_as_of time and carry chains. This helps the agent decide when to use.

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

All commutescout 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