Skip to main content
Glama

Washington DMV (Dept of Licensing)

Wa Dmv Registration Transactions

wa_dmv_registration_transactions
Read-onlyIdempotent

Count Washington State vehicle registration transactions — original registrations and renewals processed by the Department of Licensing (Washington DMV) — for one fiscal year or one calendar month, broken down by county of the registered owner, county where the transaction happened, fuel type, use class, or month. Answers "how many vehicle registrations did King County process in fiscal 2026", "monthly registration volume in Washington", "diesel registration transactions by county", and "which Washington counties process the most registrations". Each transaction is an event, so a county with 1.9 million transactions in a year has far fewer vehicles than that; for the size of Washington's registered electric fleet use wa_dmv_ev_population.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoFour-digit state fiscal year from 2017 onward, e.g. "2026". Defaults to the latest year published.
limitNoMax rows to return (default 25, max 200). Raise it to 39 to cover every Washington county.
monthNoA single calendar month as YYYY-MM, e.g. "2026-05". Takes precedence over `year`.
countyNoCounty of the registered owner, plain mixed case, e.g. "King", "Pierce", "Spokane".
group_byNoBreakdown dimension: county, transaction_county, fuel, use_class, month, fiscal_year. Defaults to county.
fuel_typeNoFuel; plain words are mapped to the published labels, e.g. "gas" → Gasoline, "flex" → Flex Fuel/Gasoline, "cng" → Compressed Natural Gas. Published labels: Gasoline, Unpowered, Diesel, Flex Fuel/Gasoline, Hybrid, Electric, Other, Propane, Compressed Natural Gas, Liquefied Natural Gas, Steam, Butane, Liquefied Petroleum Gas, Hydrogen Fuel Cell.
use_classNoUse class as published, matched as a substring, e.g. "Passenger Car", "Truck", "Trailer", "Motorcycle".
transaction_countyNoCounty where the transaction was processed, plain mixed case, e.g. "King". Differs from `county` when an owner registers away from home.

Schema Changelog

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

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds critical context beyond annotations: it clarifies that transaction counts are events, not vehicle counts, and defines the breakdown dimensions. No contradictions 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.

Conciseness5/5

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

Description is a single, well-structured paragraph that front-loads the purpose, provides concrete examples, and includes a critical clarification about transaction vs. vehicle counts. Every sentence serves a purpose; no redundant or irrelevant 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 having 8 parameters, no required ones, and no output schema, the description is highly complete. It covers purpose, usage scenarios, parameter dimensions, examples, and a key caveat. It also references a sibling tool for a related but distinct query, ensuring the agent can correctly select the tool.

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 description coverage is 100%, with every parameter documented. The description adds high-level examples and mapping hints (e.g., 'gas' → Gasoline) but does not significantly extend what the schema already provides. A score of 3 reflects adequate parameter information without additional semantic depth.

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 the tool counts vehicle registration transactions, specifies the breakdown dimensions (county, fuel type, etc.), and explicitly distinguishes from the sibling wa_dmv_ev_population tool. It directly answers example questions, leaving no ambiguity about the tool's purpose.

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?

Description provides explicit guidance on when to use (for transaction counts by various dimensions) and when not to use (for electric fleet size, directing to wa_dmv_ev_population). It includes example queries and notes that each transaction is an event, not a vehicle count, preventing misuse.

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.