wsdot-mcp-server

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

Even though readOnlyHint=true is annotated, the description adds rich behavioral details: wait times in minutes, the exact number and composition of lane entries (eleven across the four crossings), the naming convention (route codes vs. readable names), and the behavior when a crossing lacks current data (still returned, only waitTimeInMinutes omitted). This goes well beyond the annotation.

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 dense but every sentence earns its place: it lists crossings, explains lane types, clarifies naming, specifies units, and describes missing-data behavior. It is front-loaded with the primary purpose and uses a clear, structured format (colons, em-dashes, parenthetical examples). No redundant text or filler.

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 having no parameters, the tool's response is multi-faceted (11 lane entries with route codes and readable names) and the description thoroughly explains the response semantics, including edge cases like no current data. Given that an output schema exists, the description adds the necessary semantic layer to make the tool fully usable without additional context.

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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it appropriately focuses on the output structure instead. There is no ambiguity about how to call the tool.

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 exactly what the tool does with a specific verb and resource: 'Returns current vehicle wait times at WA→Canada land border crossings', listing all four crossings (I-5, SR 543, SR 539, SR 9). It is clearly distinct from sibling tools focused on ferries, mountain passes, tolls, travel times, and 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?

Explicit use-case guidance is provided: 'Use for "how long is the border wait?" questions.' This clearly signals when to invoke this tool, though it does not explicitly mention alternatives beyond the obvious domain separation from the listed siblings. No when-not-to-use is stated, but the unique scope makes it unnecessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint annotation, the description discloses the alert structure (one-line summary, title, kind, full body), explains that the body contains details like replacement sailings, and notes the important caveat that seasonal/San Juan/Sidney route IDs may be absent. This is substantial behavioral context beyond what the annotation alone provides.

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 and front-loaded with the core purpose, then expands into useful details about alert contents and route-ID resolution. Every sentence adds value without redundancy, filler, or excessive length.

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?

For a simple zero-parameter, read-only alert retrieval tool with an output schema, the description is fully complete. It explains what the alerts contain, how to interpret route IDs, and where to find additional detail, giving the agent everything needed to invoke and use the tool correctly.

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 tool has zero parameters, so the input schema is empty. Per the rubric, 0 parameters receives a baseline of 4. The description appropriately focuses on output semantics rather than parameter behavior, and no additional parameter documentation is needed.

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 opens with a specific verb and resource: 'Returns active WSF ferry service disruptions, delays, and bulletins.' It clearly identifies the tool's output as alerts and differentiates it from sibling tools like ferry routes, schedules, and terminals by emphasizing active disruptions and bulletin content.

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 usage context by instructing users to cross-reference impacted route IDs with wsdot_get_ferry_routes and warns that some route IDs may not appear. It lacks an explicit when-not-to-use comparison with the sibling wsdot_search_alerts, but for a zero-parameter read-only alerts tool, the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint annotation, the description discloses that not all alert route IDs map to returned routes, adding valuable behavioral context. This transparency helps the agent understand the tool's coverage limitations.

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?

Two concise sentences front-load the core purpose and caveats, with a direct pointer to an alternative tool. No extraneous words.

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 output schema exists, the description adequately covers purpose, relationships, and limitations. It provides enough context for correct invocation without over-explaining return values.

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 only parameter, tripDate, is fully described in the schema with format and default. The description does not add new information beyond that, so it meets the baseline for 100% schema coverage.

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 specifies the tool returns 'main WSF ferry routes operating on a given date,' with a clear verb and resource. It distinguishes itself from siblings by relating route IDs to ferry alerts and directing users to another tool for terminal IDs.

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 states when to use the tool (for routes on a given date) and provides exclusion criteria (seasonal, interisland, Sidney B.C. routes may not appear). It also advises using wsdot_get_ferry_terminals for terminal IDs, offering clear guidance on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint annotation, the description reveals critical behavioral traits: sailing times are in UTC while tripDate is a Pacific service day, requiring timezone conversion; cancellations are silently dropped rather than flagged; and remainingOnly is only meaningful for today. This adds substantial contextual information not available from annotations alone, and no contradiction exists.

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 yet comprehensive, with each sentence serving a purpose. It front-loads the main function, then covers prerequisites, parameter semantics, and caveats in a logical order. No redundant or filler content is present; every sentence adds meaningful guidance.

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 tool's complexity and the existence of an output schema, the description is exceptionally complete. It covers the core purpose, necessary prerequisite (terminal IDs), parameter nuances, timezone handling, and a critical limitation (cancellations not flagged) along with an alternative tool. This fully equips an AI agent to select and invoke the tool correctly.

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?

Although the schema describes all parameters, the description adds value beyond it. It clarifies that tripDate refers to the Pacific service day (not UTC), and that remainingOnly is specifically useful for 'next ferry' queries, which is not in the schema. This enhances understanding of parameter behavior beyond the basic field descriptions.

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 opens with a specific verb and resource: 'Returns departure times for a specific WSF ferry route on a given date.' It clearly distinguishes this from sibling tools by noting it requires numeric terminal IDs and pointing to wsdot_get_ferry_terminals for ID resolution, which is unique to this tool.

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 instructs when to use this tool and when to use alternatives: it says to use wsdot_get_ferry_terminals to resolve terminal IDs, and wsdot_get_ferry_alerts for disruptions. It also gives a concrete use case ('next ferry' queries) for remainingOnly, clarifying when that parameter is beneficial. This provides clear context and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations indicate readOnlyHint=true, and the description reinforces a read-only operation. It adds valuable behavioral context beyond annotations: the list has 20 terminals and rarely changes, which helps the agent understand the tool's stability and scope.

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?

Two sentences, front-loaded with the core return value, then usage guidance. No wasted words; every sentence earns its place.

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?

For a zero-parameter read-only list tool with an output schema, the description fully covers purpose, usage context, and expected behavior. No gaps identified.

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?

Tool has zero parameters, so there is nothing to document. The description handles this well by not inventing unnecessary detail; baseline 4 is appropriate.

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 the tool returns all WSF ferry terminals with IDs, names, and abbreviations. It also explicitly distinguishes this from sibling tools by noting it resolves terminal names to numeric IDs required by schedule and space tools.

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 instruction to call this tool first to resolve terminal IDs for use with other tools. Also adds context that the list is small and rarely changes, setting expectations for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations declare readOnlyHint=true, and the description aligns with a read-only operation. It adds functional context beyond annotations by listing the specific data returned (status, weather, temperature, elevation) and confirming coverage of all 16 passes, which helps set expectations.

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 two sentences with front-loaded purpose. The first sentence states the core function and data fields; the second adds scope (all 16 passes) and practical use cases. Every sentence adds 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 a zero-parameter tool with an output schema and read-only annotation, the description is comprehensive. It covers scope (all mountain passes), key data fields, and common use cases, leaving no significant gaps for selection or 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?

The tool has zero parameters, and the schema coverage is 100%, so there is no need for parameter explanation. The baseline of 4 applies, and the description appropriately focuses on output rather than parameters.

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's function: 'Returns current road conditions for all Washington State mountain passes' with specific data fields (status, weather, traction laws, etc.). It distinguishes itself from sibling tools (ferries, tolls, travel times) by explicitly focusing on mountain passes and listing the passes covered.

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 explicit use cases: 'Use for "is the pass open?", traction law status, or winter driving planning.' This clearly indicates when to invoke this tool, and the sibling list shows no overlapping functionality, so no alternatives are needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond readOnlyHint=true, the description discloses detailed behavior: driveUpSpaceCount's meaning (zero = full), paging by terminal (default 5, max 20), offset/limit counting terminals, totalCount counting matching terminals, and varying page sizes. This is rich context that annotations don't provide, and it contradicts nothing.

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 dense yet efficient—every sentence earns its place. It opens with the primary action, then covers typical questions, key fields, paging semantics, and caveats, all in a well-organized paragraph 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?

The tool has no required parameters, is read-only, and has an output schema. The description covers all essential behavioral aspects: what the data represents, how to interpret the key field, the paging model, and how to coordinate with sibling tools. Nothing important is left unexplained.

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 100%, so baseline is 3, but the description adds meaningful nuance: offset/limit select whole terminals, totalCount counts terminals not sailings, and every sailing of a returned terminal is included. This goes beyond the schema's per-parameter descriptions, giving real semantic insight into the paging parameters.

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 real-time drive-up and reservable vehicle space at WSF terminals for upcoming sailings, and explicitly names the use cases ('will I make the ferry?'). It distinguishes itself from siblings by referencing wsdot_get_ferry_terminals for terminal IDs and wsdot_get_ferry_schedule for schedule 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?

The description gives explicit when-to-use guidance ('Use for...'), mentions the optional terminal filter with a pointer to wsdot_get_ferry_terminals, and clarifies that arrivingTerminalIds are what the schedule tool expects, steering away from itineraryLabel. This effectively differentiates from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark the operation as readOnlyHint. The description adds significant behavioral context: rates are time-banded and dynamic, results are paged with offset/limit, and the stateRoute field format is explained. This goes beyond the annotation and helps the agent understand response semantics and paging behavior.

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 three sentences, each earning its place: the first lists covered facilities, the second explains dynamic time-banding, and the third covers stateRoute formatting and paging. It is dense but free of fluff, well-structured and front-loaded with the core purpose.

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 output schema exists and the readOnly annotation is present, the description provides all needed context: facility list, dynamic nature, paging details, and a note about the stateRoute field. Nothing essential is missing for an agent to correctly invoke and understand the result set.

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?

Input schema covers both parameters with detailed descriptions, so baseline is 3. The description adds that offset/limit are used for paging and mentions 'the notice reports the next offset', which is useful but only slightly enhances the schema's existing documentation. No additional parameter-level detail is provided.

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 dynamic toll rates for specific WA facilities, listing them explicitly. The verb 'Returns' plus the resource 'current dynamic toll rates' makes the purpose unambiguous and distinguishes it from sibling tools like ferry schedules or travel times.

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 gives clear context that this tool is for toll rates on specific routes, which implicitly tells when to use it. However, it does not explicitly mention alternatives or when not to use it, though the unique scope makes exclusions unnecessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint annotation, the description adds meaningful behavioral details: the route filter's dual matching behavior, the congestion interpretation ('When current time exceeds average, the corridor is congested'), and pagination semantics with offset/limit and the notice for next offset. No annotation contradiction exists.

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 compact and front-loaded: it states the core function, then use cases, then behavioral details. Each sentence adds useful information without redundancy, and the length is appropriate for the tool's complexity.

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 rich input schema and available output schema, the description is complete: it covers what the tool returns, when to use it, how filtering works, how congestion is determined, and how paging works. No critical guidance is missing for correct invocation and interpretation.

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?

Input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description mentions route matching and paging, but the schema already explains these thoroughly; the only marginal addition is the 'notice reports the next offset' detail, which does not elevate the score.

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 opens with a specific verb and resource: 'Returns current vs. average travel times for named WA highway corridors.' It lists concrete routes and clearly distinguishes this from sibling tools like ferry alerts or toll rates by focusing on highway corridor travel times.

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 clear use cases: 'Use for "how congested is I-5?" or commute time estimates.' It does not explicitly name alternatives or exclusion criteria, but the mention of corridor-specific congestion makes the intended scenario clear relative to the other WSDOT tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description adds behavioral context beyond the readOnlyHint annotation, including real-time data delays (30–60 seconds) and that many fields are null for non-operating vessels. 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?

Two sentences that clearly state the tool's output and usage. Every sentence adds value, no wasted words.

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 presence of an output schema, the description appropriately focuses on behavior and usage. It covers real-time nature, lag, and null fields, which is sufficient for a parameterless 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?

There are no parameters, so the description does not need to explain them. The baseline for 0 params is 4, and the description adds value by detailing output fields and caveats.

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 returns real-time AIS positions, speed, heading, ETA, and dock status for active WSF vessels, and mentions example use cases. It is distinct from sibling tools (e.g., wsdot_get_ferry_alerts, wsdot_get_border_waits) which cover different data.

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 'Use for "where is the ferry now?", vessel tracking, or checking if a vessel is in service.' It also notes caveats like data lag and null fields. It does not explicitly mention when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations provide readOnlyHint=true, so the safe-read nature is known. The description adds valuable behavioral detail: matching against the alert's full extent, ordering by alertId, pagination with offset/limit, and the notice reporting the next offset. This goes beyond the annotation without contradicting it.

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 four sentences, each earning its place: purpose, filter options, default behavior, and pagination. It is front-loaded with the core action and avoids redundancy. No filler.

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?

The tool has 6 optional parameters and an output schema, so return values are covered elsewhere. The description covers all key user-facing behaviors: what alerts are returned, how filters work, how to get all alerts, and how paging works. This is complete for a search/list 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 description coverage is 100%, with each parameter already thoroughly described (e.g., startMilepost explains overlap matching). The main description adds no new parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource: 'Returns active WA highway alerts: incidents, construction, closures, and restrictions.' This clearly distinguishes it from sibling tools like ferry alerts or mountain passes. The scope (active, statewide) and filtering capability are explicit.

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 gives clear usage context: filter by route, region, or milepost, and 'Omit all filters to return all current statewide alerts.' It also explains pagination behavior. It does not explicitly contrast with alternatives, but sibling tool names make the domain boundaries obvious, so exclusions are implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint annotation, the description discloses that camera images are copyrighted, that only metadata/URLs are returned, and that results are ordered by cameraId with pagination reporting the next offset. This gives the agent concrete expectations about response behavior and limitations.

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 compact and front-loaded, covering purpose, limitations, filters, and pagination in three sentences with no redundant detail. Every sentence adds actionable 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?

With a rich input schema, output schema, and readOnlyHint annotation, the description complements structured data by explaining overall behavior, pagination, and the metadata-only constraint. It is comprehensive for a search tool, though it could theoretically mention that all filters are optional, which the schema already implies.

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 already provides detailed descriptions for all six parameters, so the description adds little new parameter-specific information. It summarizes filter options (state route, region, milepost) but does not elaborate beyond what the schema covers, warranting the baseline score.

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 opens with a specific verb and resource ('Returns WSDOT highway camera locations, descriptions, and image URLs'), clearly distinguishing it from sibling tools like ferry or toll tools. It also clarifies output scope (metadata/URLs, not image bytes), leaving no ambiguity about the tool's function.

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 states when to use the tool—any need for WSDOT camera info—and adds an exclusion that only metadata and URLs are returned, not image bytes, so users know not to expect images. It also provides paging instructions and mentions supported filter types, though it does not explicitly name alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.