Skip to main content
Glama

get_lane_closures

Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
routeNo
centerNo
districtNo
radius_kmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations indicate readOnlyHint and openWorldHint. Description adds refresh rate (5-minute cache), data source, exclusion of shoulder-only work, and detailed explanation of closure_class meanings. No contradictions. Provides rich behavioral context 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.

Conciseness4/5

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

Description is multi-paragraph but dense with information. Each sentence adds value. Could be slightly more structured (e.g., bullet points), but effectively communicates all necessary details without fluff.

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?

No output schema, so description explains output fields: closure_class, estimated_delay_minutes, lanes. Also covers refresh rate and data source. For a read-only tool with 4 parameters and no nested objects, this is comprehensive and leaves no major gaps.

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 0% description coverage for parameters. Description fully compensates by explaining each parameter: route with examples, district with district numbers and regions, center as lat,lon string, radius_k with default 40 km. This adds significant meaning beyond the schema.

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?

Description clearly states tool returns physically in-place Caltrans lane closures right now. It specifies data source (LCS) and excludes scheduled closures, distinguishing it from a construction calendar. This differentiates it from sibling tools like get_incidents or get_road_signs.

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?

Provides explicit context: use for current closures only, not scheduled. Explains filters (route, district, center/radius) with examples and guidance (e.g., center catches all roads around a place). Does not explicitly state when not to use, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.