Skip to main content
Glama

I-5 conditions now

dogpolicies_i5_conditions
Read-onlyIdempotent

Is I-5 open right now: lane closures, chain controls, road weather and sign messages on the freeway in California, and the nearest dog stop to each? Live state, not rules: Caltrans feeds fetched within the last 15 minutes (fetched_at in the result), not verified rules. Covers the Grapevine and every other stretch of I-5 in California. Other highways are not covered. Inputs: from_mile and to_mile, or near={lat, lon} with direction and ahead_miles; with none, all of I-5 in California. Each condition is placed on the I-5 centerline (mile, s meters from San Ysidro) and matched to the nearest dog stop. If the feeds cannot be read the answer has outcome unavailable and the address of the live Caltrans page. A result older than two hours is marked stale.

Examples:

  • "Is there a closure or chains on the Grapevine right now?" -> from_mile=170, to_mile=222

  • "Weather and closures in the next 60 miles northbound from Redding" -> near={lat:40.59, lon:-122.39}, direction="north", ahead_miles=60

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dogpolicies_i5_conditions"
  }
}

Input Schema

NameRequiredDescriptionDefault
nearNoA point on or near I-5
to_mileNoEnd of a mile range
directionNoDirection of travel from nearnorth
from_mileNoStart of a mile range
ahead_milesNoWindow in miles from near
response_formatNo'markdown' for readable text, 'json' for structured datamarkdown

Output Schema

NameRequiredDescriptionDefault
codeNoWith an outcome other than ok: not_found, invalid, unavailable
nextNoCalls that would answer the question, in words
as_ofYesDate the data was built (YYYY-MM-DD)
signsYes
staleNoTrue when the document is older than two hours
noticeYes
sourceYes
windowYes
licenseYes
messageNoWhat happened, in a sentence
nearestNoWhen nothing is inside the radius: the nearest places in the data, with distance_miles
outcomeNoAbsent or ok: a normal answer. no_match: nothing in the data matches, see did_you_mean, nearest and next. bad_input: the arguments cannot be used as given, see next. partial: some of the ids were found, see missing. unavailable: a live source could not be read. None of these is an error.
weatherYes
acceptedNoWith bad_input: each argument that could not be read, with the values it accepts
closuresYes
fetched_atYesWhen the loop fetched the feeds; null when no document could be read
nearest_i5NoWith a point too far from I-5: the nearest point on I-5 and how far it is
did_you_meanNoClose matches to what was asked for: towns, places, slugs or brands, best first
resolved_fromNoSet when a word was read as the value the tool uses: hotel as lodging, NB as north. Each key is the argument; asked is what was sent, used what it was read as
chain_controlsYes
attribution_urlYes
attribution_textYes
chains_in_effectYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / accepted
      Added value: +{
      +  "additionalProperties": {
      +    "items": {
      +      "type": "string"
      +    },
      +    "type": "array"
      +  },
      +  "description": "With bad_input: each argument that could not be read, with the values it accepts",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
    • addedOutput schema / properties / resolved_from
      Added value: +{
      +  "additionalProperties": {
      +    "additionalProperties": {},
      +    "properties": {
      +      "asked": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        ]
      +      },
      +      "used": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "asked",
      +      "used"
      +    ],
      +    "type": "object"
      +  },
      +  "description": "Set when a word was read as the value the tool uses: hotel as lodging, NB as north. Each key is the argument; asked is what was sent, used what it was read as",
      +  "propertyNames": {
      +    "type": "string"
      +  },
      +  "type": "object"
      +}
  2. Changed10 schema fields changed
    • addedOutput schema / properties / code
      Added value: +{
      +  "description": "With an outcome other than ok: not_found, invalid, unavailable",
      +  "type": "string"
      +}
    • addedOutput schema / properties / did_you_mean
      Added value: +{
      +  "description": "Close matches to what was asked for: towns, places, slugs or brands, best first",
      +  "items": {
      +    "additionalProperties": {},
      +    "properties": {},
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / fetched_at / description
      Added value: +"When the loop fetched the feeds; null when no document could be read"
    • changedOutput schema / properties / fetched_at / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • addedOutput schema / properties / message
      Added value: +{
      +  "description": "What happened, in a sentence",
      +  "type": "string"
      +}
    • addedOutput schema / properties / nearest
      Added value: +{
      +  "description": "When nothing is inside the radius: the nearest places in the data, with distance_miles",
      +  "items": {
      +    "additionalProperties": {},
      +    "properties": {},
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / nearest_i5
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "With a point too far from I-5: the nearest point on I-5 and how far it is",
      +  "properties": {},
      +  "type": "object"
      +}
    • addedOutput schema / properties / next
      Added value: +{
      +  "description": "Calls that would answer the question, in words",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / outcome
      Added value: +{
      +  "description": "Absent or ok: a normal answer. no_match: nothing in the data matches, see did_you_mean, nearest and next. bad_input: the arguments cannot be used as given, see next. partial: some of the ids were found, see missing. unavailable: a live source could not be read. None of these is an error.",
      +  "enum": [
      +    "ok",
      +    "partial",
      +    "no_match",
      +    "bad_input",
      +    "unavailable"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / stale
      Added value: +{
      +  "description": "True when the document is older than two hours",
      +  "type": "boolean"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the read-only/idempotent annotations: it discloses feed freshness (15 minutes, with fetched_at in the result), a staleness threshold of two hours, and a defined failure mode ('outcome unavailable' plus the live Caltrans page address). It also explains how results are georeferenced (I-5 centerline mile, meters from San Ysidro) and matched to dog stops.

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?

Front-loads the user-facing question, then scope, freshness, inputs, mechanics, and examples in a sensible order; every paragraph is doing work. Minor redundancy in 'Live state, not rules: ... not verified rules' and a slightly dense mechanics sentence keep it from being airtight.

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 six optional parameters, a nested near object, and an output schema that covers return values, the description supplies everything an agent needs: geographic scope, freshness expectations, the empty-input default, and the degraded/unavailable outcome. Nothing material about calling it correctly is left unstated.

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 100%, so the baseline is 3, but the description adds real meaning: from_mile/to_mile is a range, near combines with direction and ahead_miles to form a directional window, and the no-parameter case means all of I-5 in California. Concrete example values (from_mile=170, to_mile=222 for the Grapevine) make the mile convention usable without guessing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete question the tool answers ('Is I-5 open right now') and enumerates the specific resources: lane closures, chain controls, road weather, sign messages, plus nearest dog stop. Scope is pinned to I-5 in California and explicitly excludes other highways, which separates it from a general road-conditions sibling, though no sibling is named.

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?

'Live state, not rules' plus the Caltrans-feed and 15-minute freshness framing tells the agent this is for current conditions rather than stored policy, which is the key routing decision against rule-lookup tools. Two worked examples map natural questions to parameter sets, but there is no explicit 'use X instead when...' exclusions.

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.