Skip to main content
Glama

commutescout

by io.github.nicglazkov

get_wildfires

Read-only

Active California wildfires, flagged when close to a major highway.

Data: the interagency WFIGS current-wildfire feed (NIFC) - name, size in
acres, percent contained, discovery date. Points are each fire's ORIGIN,
not its perimeter: a large fire can affect roads far from this point.
Refresh: 5-minute cache; size/containment typically update once or twice
a day. Small, fast-moving local fires may appear in CHP incident logs
(get_incidents, type "FIRE-Report of Fire") before this feed has them.

Filters:
- near_route (e.g. "I-5", "101") - only fires within ~10 miles of that
  highway's corridor line.
- center "lat,lon" with radius_km - fires around a place, regardless of
  highway.
Without either, every active CA fire is returned, each carrying a
`near_highways` list of major corridors within ~10 miles (empty = not
near a covered major highway; it may still affect local roads).

This tool does NOT know about road closures caused by fires - cross-check
get_incidents and get_lane_closures for the affected area.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
centerNo
radius_kmNo
near_routeNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), description adds refresh rate (5-min cache), update frequency (once/twice daily), data limitations (origin vs perimeter, small fires may lag), and the near_highways attribute. No contradictions.

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?

Well-structured with clear sections: purpose, data details, filter options, and warnings. Every sentence adds value; no fluff. Front-loaded with essential information.

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?

For a read-only list tool with no output schema, the description covers data fields, geographic scope (California), filtering options, and limitations. Cross-references to sibling tools ensure the agent can make informed decisions.

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?

Despite 0% schema description coverage, the description fully explains each parameter: near_route (highway name with ~10 mile radius), center (lat,lon with radius_km, default 50), and the behavior when neither is provided. This compensates entirely for the missing 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 returns active California wildfires, with specific data source (WFIGS/NIFC) and fields (name, size, containment, discovery). It distinguishes from sibling tools like get_incidents by noting that small fires may appear there first.

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?

Explicitly describes when to use filters (near_route or center) and the behavior without filters (returns all active CA fires). Also explicitly states what the tool does not do (road closures) and recommends cross-checking with get_incidents and get_lane_closures.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct aspect of road conditions: region summary, route-specific, cameras, chains, incidents, closures, out-of-state, signs, wildfires, and ranking. Even related tools like check_region and check_route have clear, differentiated purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_region, check_route, get_cameras, etc.). The verbs 'check' and 'get' are used appropriately for different actions, maintaining predictability.

Tool Count5/5

With 10 tools, the server is well-scoped. Each tool provides a specific, non-redundant function for the domain of California road conditions, fitting perfectly within the ideal 3-15 range.

Completeness4/5

The tool set covers major aspects: incidents, closures, chains, wildfires, cameras, signs, and region/route summaries. Missing dedicated traffic flow/speed data or construction schedules, but overall robust for trip planning and condition awareness.

Resources