Skip to main content
Glama

Ia Dmv Driver License Stations

ia_dmv_driver_license_stations
Read-onlyIdempotent

Find Iowa DOT driver license stations with street address, per-day opening hours, phone, coordinates, whether the station does commercial driver license (CDL) testing, and the live queue-camera image URLs Iowa points at its own waiting rooms so a caller can see how long the line is right now. Covers all 18 Motor Vehicle Division stations statewide, so it answers "Iowa driver license station in Des Moines", "where can I take the CDL test in Iowa", "what time does the Mason City DL station open on Saturday", or "show me the wait at an Iowa DMV". Filter by city, station name or CDL testing; call with no arguments for all 18.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity name, matched as a substring, e.g. "Des Moines", "Mason City", "Cedar Rapids".
nameNoStation-name substring, e.g. "Mason City", "Ankeny".
limitNoMax stations to return (default 20, max 50).
cdl_onlyNoSet true to keep only stations that perform commercial driver license (CDL) testing.

Schema Changelog

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

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds that it returns live queue-camera image URLs and covers all 18 stations statewide, providing extra 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.

Conciseness5/5

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

Two sentences: first lists outputs, second gives usage examples. No wasted words, front-loaded with key 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?

Despite no output schema, the description thoroughly explains what the tool returns (address, hours, phone, coordinates, CDL flag, queue URLs) and that it covers all 18 stations. Example queries cover typical use cases.

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

Parameters3/5

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

Schema already describes all 4 parameters with 100% coverage. Description mirrors the filtering options (city, station name, CDL testing) without adding deeper semantics, meeting the baseline for good schema coverage.

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 'Find Iowa DOT driver license stations' with specific verb 'find' and resource, and lists the exact fields returned. It distinguishes itself from unrelated sibling tools like bet_research or deep_research.

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?

Explicitly provides example queries that the tool answers, and notes that calling with no arguments returns all 18 stations. Does not explicitly list when not to use, but sibling tools are dissimilar so guidance is sufficient.

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.