commutescout
Server Details
Live California road conditions: CHP incidents, Caltrans closures, chain controls, and wildfires.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- nicglazkov/commutescout
- GitHub Stars
- 2
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 10 of 10 tools scored. Lowest: 4.1/5.
Each tool has a unique and clearly defined purpose: region overview, route check, cameras, chain controls, incidents, lane closures, multi-state events, road signs, wildfires, and route ranking. No overlap exists.
Tool names follow a consistent verb_noun pattern: 'check_' for overviews, 'get_' for data retrieval, and 'rank_' for ranking. The pattern is predictable and semantically grouped.
With 10 tools, the server is well-scoped for a traffic and road conditions service. Each tool covers a distinct aspect without being excessive or insufficient.
The tool set provides comprehensive coverage for its domain: current conditions (region, route, incidents, closures, chain controls, weather signs, wildfires, cameras) and even multi-state events and route ranking. No obvious gaps for its stated purpose.
Available Tools
10 toolscheck_regionARead-onlyInspect
Full current-conditions report for a California region.
Use this for area-scale questions ("how is the Bay Area?", "what's
happening in SoCal?") instead of stitching together point queries. It
sweeps every source over the whole region at once: CHP incidents
(severity-sorted, worst first), lane closures in place (full closures
called out), chain controls, and wildfires inside the region.
Regions: Bay Area, Sacramento metro, Tahoe/Sierra, Central Valley,
Southern California, San Diego, Central Coast, North State. An
unrecognized region name returns the list.
Large regions are capped to the most severe items; the counts are
always exact and the response says when a list was truncated.
Freshness: CHP ~1/min fetched live, everything else 5-minute cache.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint annotations, the description details data sources, severity sorting, truncation with exact counts, and data freshness (CHP live, others cached).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured, front-loaded with purpose, and each sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers input, behavior, limitations, freshness, and error handling, fully meeting the needs for a report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions and 0% coverage; the description lists all valid region values and explains behavior for unrecognized input (returns list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a full current-conditions report for a California region, listing specific data types (CHP incidents, lane closures, chain controls, wildfires) and contrasting with point queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (area-scale questions) and lists valid regions, but does not explicitly mention alternative sibling tools for non-region queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_routeARead-onlyInspect
Check current conditions along a major California highway corridor.
The flagship trip-check tool: give it a start and end place and it
returns everything active along that stretch right now - CHP incidents,
lane closures physically in place, chain controls, and wildfires within
~10 miles - ordered by miles from the start, plus a summary.
ALWAYS pass from_coords and to_coords ("lat,lon") when you know where
the places are - for landmarks, small towns, or anything not a major
city they are required for a good answer. Coordinates do two things:
they let unlisted places resolve to the nearest corridor (e.g. "Alice's
Restaurant" snaps to I-280 on the Peninsula), and they CLIP the route to
the span actually being driven, so a trip to a mid-corridor destination
doesn't report events beyond it.
Corridors covered: I-80 Sacramento-Reno, US-50 to South Lake Tahoe, I-5,
US-101, SR-17, SR-99, SR-1, I-15 to Vegas, Bay Area freeways, Tahoe-area
routes. This is NOT a general router: if nothing matches (even with
coordinates), the response lists the covered corridors; fall back to the
filtered tools with center= for anything else.
Freshness: CHP incidents refresh about once a minute; closures, chain
controls, and fires are on a 5-minute cache. Current conditions only -
this cannot forecast tomorrow's weather or closures.
| Name | Required | Description | Default |
|---|---|---|---|
| to_place | Yes | ||
| to_coords | No | ||
| from_place | Yes | ||
| from_coords | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint and openWorldHint. Description adds freshness details (1 min for incidents, 5 min for others), confirms current conditions only, and no forecasting. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with overview, coordinate usage, coverage, exclusions, and freshness. Each sentence adds value, though a bit verbose; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameters, coverage, fallbacks, data freshness, and limitations. No output schema but describes response content (incidents, closures, order, summary). Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions. The description adds meaning: from_place/to_place are place names; from_coords/to_coords are 'lat,lon' strings, optional but recommended, for resolution and route clipping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool checks current conditions along a major California highway corridor, listing specific resources (CHP incidents, lane closures, chain controls, wildfires). It clearly distinguishes from siblings like check_region and get_incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends passing from_coords and to_coords for landmarks/small towns, explains why (resolution and clipping). States it is not a general router, and provides fallback to filtered tools with center=.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_camerasARead-onlyInspect
Live Caltrans roadside camera snapshots near a point or on a route.
Data: ~3,000 in-service Caltrans cameras statewide. Every returned
image_url was verified live moments ago (offline cameras that serve a
placeholder frame are filtered out), so images can be shown directly.
Snapshots refresh roughly every minute; stream_url (when present) is
an HLS video stream.
Filters: center "lat,lon" (required unless route is given) with
radius_km; route (e.g. "I-80", "50") narrows to that highway. Results
sort nearest-first when a center is given. Use a camera to let the
user SEE conditions: fog on the pass, snow on the pavement, traffic
density at an interchange.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| route | No | ||
| center | No | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds significant behavioral details: images are verified live, offline cameras filtered out, refresh rate ~1 minute, stream_url when present is HLS, and results sort nearest-first when a center is given. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, followed by data details, filter explanations, and a usage example. Every sentence adds value, with no redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers purpose, data source, verification, refresh rate, filters, and sort order. It lacks explicit mention of limit behavior and the exact return structure, but the core functionality is well-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains center (required unless route given, lat,lon format), route (e.g., I-80), and radius_km. However, the limit parameter is not mentioned, leaving some parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live Caltrans roadside camera snapshots near a point or on a route, specifying the data source and filtering. It distinguishes itself from sibling tools like get_incidents or get_lane_closures by focusing on visual camera feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using cameras to see conditions (fog, snow, traffic), providing clear when-to-use guidance. It also explains filter options but does not explicitly exclude alternative tools, though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chain_controlsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| route | No | ||
| center | No | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world; description adds caching, explicit off-season behavior, and data source, exceeding annotation coverage. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear topic sentences, but slightly verbose. Each section serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions response behavior. Covers essential aspects given three optional parameters and dynamic data. Could detail response format more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description compensates well by explaining route examples, center format, and radius_km default, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool returns current chain-control requirements on California mountain highways, specifies specific routes and levels, distinguishing from sibling tools like get_incidents or check_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on seasonal usage, refresh rate, and advice to inform users about data freshness and carry chains. Lacks explicit comparison to sibling tools for when to use this one instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_incidentsARead-onlyInspect
Live CHP traffic incidents statewide, optionally filtered.
Data: the California Highway Patrol statewide computer-aided dispatch
feed - collisions, traffic hazards, disabled vehicles, closures as CHP
logs them. Refreshes about once a minute; incidents disappear when CHP
closes the log. Fetched live on every call.
Filters (combinable):
- highway: a route like "I-80", "US 50", "17", "Hwy 99". Matches
incidents whose location text mentions that route.
- center: "lat,lon" with radius_km - incidents within that circle. THIS
IS THE RIGHT FILTER FOR A TOWN OR PLACE NAME: use your knowledge of
where the place is (e.g. Coyote, CA -> "37.22,-121.74") with radius_km
15-30. A circle catches every road around the place, not just one
highway.
- area: substring match on the CHP dispatch-area name. These are CHP
communication-center names ("Hollister Gilroy", "East Sac", "Golden
Gate"), NOT town names - do not pass a town here. There is no county
filter because CHP's feed carries no county field; for a county, use
center on the county seat with a radius covering the county.
Limits: locations are free-text from dispatchers; a few incidents lack
usable coordinates and are omitted. No history - current logs only.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| center | No | ||
| highway | No | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds behavioral details: live refresh (~1 minute), incidents removed when closed, free-text locations, missing coordinates for some, no history. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opening sentence, data source, refresh behaviour, then filter explanations with clear sections. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description is thorough. It covers data source, refresh, filters, and limitations. Missing a brief note on return format, but for a live feed this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains each parameter: highway (route matching), center (lat,lon with radius_km), area (CHP dispatch area, not town), and radius_km (default 40). Provides examples and context for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides live CHP traffic incidents statewide with optional filters. It specifies the verb ('Live... incidents') and resource, and distinguishes from sibling tools like get_cameras by focusing on incidents and specific filters (highway, center, area).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use each filter: center for places, highway for routes, area for CHP areas. It warns against passing town names to area and explains the lack of county filter, suggesting alternative use of center with radius.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lane_closuresARead-onlyInspect
Caltrans lane and road closures physically in place RIGHT NOW.
Data: the Caltrans Lane Closure System (LCS). Only closures that crews
have actually established (CHP code 1097) and not yet picked up are
returned - scheduled-but-not-started closures are excluded, so this is
"what is blocking lanes now", not a construction calendar.
Refresh: 5-minute cache over per-district Caltrans feeds.
Filters: route (e.g. "I-80", "US 101", "1"); district (Caltrans district
1-12, e.g. 3 = Sacramento/Tahoe, 4 = Bay Area, 7 = Los Angeles);
center "lat,lon" with radius_km - closures whose begin or end point is
inside the circle. For a town or place, center is the filter that
catches work on EVERY road around it, including small state routes.
Read closure_class on each record, it is what the closure means for
through traffic:
- "full-roadway": the road itself is closed in that direction. The only
class that means "you can't drive through".
- "ramp": a ramp or connector is closed (even when the raw record says
"Full", that means the ramp is fully closed, not the highway).
- "one-way-traffic": alternating single lane with flagging; passable
with delays. Common on two-lane mountain roads.
- "alternating-lanes", "moving", "traffic-break": rolling or brief work;
minor delays.
- "lane": some lanes closed; the lanes field says how many of how many.
estimated_delay_minutes is present when crews reported one.
Shoulder-only work is excluded entirely.
| Name | Required | Description | Default |
|---|---|---|---|
| route | No | ||
| center | No | ||
| district | No | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but description adds significant behavioral details: data source (Caltrans LCS), 5-minute cache, only CHP code 1097 closures, meaning of closure_class field, and exclusion of shoulder-only work. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and front-loaded key message. Each paragraph adds value, though slightly lengthy. Could be tightened but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return fields (closure_class, lanes, estimated_delay_minutes) and what each class means. Covers exclusions, cache refresh, and filter interactions. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). Description compensates fully by explaining each parameter: route with examples, district with district numbers and regions, center format and purpose, radius_km default. Provides clear, actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns current physical lane and road closures from Caltrans, distinguishing from scheduled or shoulder-only closures. Contrasts with sibling tools like get_incidents and get_cameras through specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on filters (route, district, center with radius_km) and explains what each filter does. Mentions exclusions (scheduled, shoulder-only) and hints at when to use center for local roads. Does not directly name sibling tools but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nearby_eventsARead-onlyInspect
Live road events near a point anywhere CommuteScout covers, not just California: 32 states today, growing.
Data: the same multi-state feeds the live map shows, normalized -
state DOT incidents, roadwork and closures, chain and traction
advisories, and nationwide wildfires. Every event names its
publishing agency in the source field. Coverage varies by state
(some publish roadwork only; docs/state-coverage.md has the
matrix); states added later appear here automatically.
For CALIFORNIA questions prefer the dedicated tools above (richer
detail: dispatch logs, lane counts, chain levels). Use THIS tool
for any location outside California, near a state border, or as a
supplement when a California tool comes back empty.
center is "lat,lon". kinds is a comma list from: incident, closure,
chain, fire, sign, rwis, camera. radius_km caps at 160.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | incident,closure,chain,fire | |
| center | Yes | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: data source (multi-state feeds, same as live map), event types (incidents, roadwork, closures, advisories, wildfires), publishing agency in source field, coverage variability, and automatic addition of states. No contradiction with readOnlyHint and openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with purpose, followed by data details and usage guidelines. Every sentence is informative with no waste, despite being fairly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multi-state, multiple event types, no output schema), the description is comprehensive: coverage scope, data sources, parameter explanations, usage guidance, and reference to external docs. It provides sufficient context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains parameters: 'center is "lat,lon"', 'kinds is a comma list from: incident, closure, chain, fire, sign, rwis, camera' with default, and 'radius_km caps at 160'. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Live road events near a point' and specifies the nationwide scope ('not just California: 32 states today, growing'). It identifies the resource (road events) and distinguishes from California-specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For CALIFORNIA questions prefer the dedicated tools... Use THIS tool for any location outside California, near a state border, or as a supplement when a California tool comes back empty.' This clearly defines when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_road_signsARead-onlyInspect
What Caltrans changeable message signs are displaying right now.
Data: statewide CMS sign text, blank and out-of-service signs already
filtered - every record is a message a driver is physically seeing.
Signs carry the road's operational truth ("CHAINS REQUIRED 10 MI
AHEAD", "FULL CLOSURE HWY 96 DUE TO FIRE", "PREPARE TO STOP"), often
before the event shows up in any other feed. Refresh: ~2-minute cache.
Filters: route (e.g. "I-80") and/or center "lat,lon" with radius_km.
Quote sign text verbatim to the user - it is the most current and
most local signal this server has.
| Name | Required | Description | Default |
|---|---|---|---|
| route | No | ||
| center | No | ||
| radius_km | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining data filtering (blank/out-of-service signs removed) and a ~2-minute cache refresh. It aligns with readOnlyHint and openWorldHint, adding valuable behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~120 words), well-structured with clear sections (data note, refresh, filters, usage tip), and every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers data source, filtering, and usage adequately but does not specify the exact fields returned (e.g., sign text, location). For a simple read tool, this is mostly sufficient but slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains parameters qualitatively: route (example 'I-80'), center ('lat,lon' format implied), and radius_km (default 80). It adds meaning but lacks explicit format for center and allowed route values, leaving some details unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current Caltrans changeable message sign text, filtering out blank/out-of-service signs. It distinguishes itself from siblings by focusing on real-time sign messages, which is unique among tools like get_incidents or get_cameras.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: signs offer operational truth before other feeds, and it instructs to quote sign text verbatim. However, it does not explicitly compare to sibling tools or state when not to use this tool, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wildfiresARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| center | No | ||
| radius_km | No | ||
| near_route | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. Description adds many behavioral details: data source (WFIGS), origin vs perimeter, 5-minute cache, update frequency for size/containment, and what it does not know (road closures). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, data source, refresh, filters, limitations). Slightly lengthy but each sentence adds value. Front-loads core purpose. Could be trimmed slightly but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple filter options, data source origin vs perimeter, output behavior with near_highways) and no output schema, the description is comprehensive. It explains what the tool returns, how filters work, caching, and limitations like not knowing road closures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains all three parameters in detail: near_route filters within ~10 miles of a highway corridor line; center+radius_km filters around a place; without either, returns all fires with near_highways list. Adds significant meaning beyond schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Active California wildfires, flagged when close to a major highway.' It identifies the specific data source (WFIGS/NIFC), the attributes returned (name, size, containment, discovery date), and distinguishes from siblings like get_incidents for small fires.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when to use: for active CA wildfires, especially near highways. Provides alternatives: for small fires use get_incidents, for road closures cross-check get_incidents and get_lane_closures. Clarifies filter behavior (near_route, center+radius_km) and default behavior (returns all fires).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_routesARead-onlyInspect
Which major corridors have the most going on right now.
Answers broad questions like "what are the busiest routes", "where is traffic worst", or "which highways should I avoid today" across all 17 tracked corridors. by="activity" ranks on live events (full closures weigh most, then incidents, lane closures, chain controls); by="congestion" ranks on measured speed vs free-flow at each corridor's midpoint and needs the traffic feed to be configured - if it is not, the ranking silently falls back to activity.
Each entry carries the counts and a one-line reason, so the answer can say WHY a corridor ranks where it does, not just list names.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | activity | |
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds that congestion ranking requires the traffic feed to be configured, silently falling back to activity. It also mentions output includes counts and reasons, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and largely concise, starting with a clear high-level purpose and then detailing the two ranking modes and output. A minor redundancy in the parentheses could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains that each entry carries counts and a one-line reason, and the answer can provide justification. It does not specify exact fields, but for a ranking tool with two parameters this is reasonably complete. The silent fallback and requirement for traffic feed are well noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the 'by' parameter's two values and ranking logic, but does not describe the 'limit' parameter. The non-explicit coverage leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'rank' and resource 'routes', clarifying it is an aggregation tool. It distinguishes from sibling tools that check specific regions or get individual data, by stating it answers broad questions across all 17 tracked corridors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it answers broad questions like 'what are the busiest routes' and explains the two ranking modes (by activity or congestion) and the silent fallback. It does not explicitly state when not to use, but the context implies for specific route details one should use sibling tools like check_route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!