wsdot-mcp-server

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

Annotations declare readOnlyHint=true. Description adds behavioral details: wait times in minutes, omission of no-data crossings, explanation of crossingName vs readable name. 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?

Four sentences with no wasted words. Purpose stated first, then specific details. Efficient and well-structured.

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 no input parameters and presence of output schema, description sufficiently covers the tool's behavior: which crossings, what data returned, and handling of missing data.

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 has 0 parameters (100% coverage), so baseline is 4. However, description mentions 'crossingName is a route code' which implies a parameter not present in schema, causing confusion. No actual parameter info is needed or 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?

Description clearly states the tool returns current vehicle wait times at specific WA→Canada border crossings, listing the crossings and distinguishing from sibling tools. The verb 'returns' and resource 'wait times' are specific.

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?

Explicitly states 'Use for "how long is the border wait?" questions', providing clear context. No exclusions or alternatives mentioned, but for a simple read tool this is adequate.

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 declare readOnlyHint=true. Description adds valuable behavioral context: the tool returns active disruptions and alerts that some route IDs (seasonal, interisland, international) may not appear in the routes tool for a given date, which is beyond what annotations provide.

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, no wasted words. Purpose is front-loaded, cross-reference guidance and caveat are efficiently communicated. Ideal conciseness.

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 zero parameters and the presence of an output schema, the description fully covers the tool's purpose, output characteristics, and important limitation about route IDs. 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?

With zero parameters, schema coverage is 100% by default. Description adds meaning by explaining the output and caveats about route ID resolution, which compensates for the absence of parameter documentation.

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 'active WSF ferry service disruptions, delays, and bulletins', specifying the resource (ferry alerts) and action (get). It distinguishes from sibling tools like wsdot_get_ferry_routes by mentioning cross-reference with route 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?

Description explicitly advises cross-referencing with wsdot_get_ferry_routes, providing clear usage context. It does not explicitly state when not to use, but the context is sufficiently clear for a simple, parameterless tool.

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 that it returns 'main' routes and explains the relationship to alerts, but does not detail the output format.

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?

Three concise sentences, front-loaded with the primary purpose, followed by important caveats and cross-references, no wasted text.

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?

Covers the scope (main routes), exceptions (missing alert routes), and related tools (terminals). With an output schema present, return value details are not required.

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 parameter tripDate is fully described in the schema (100% coverage); the description adds no additional syntax or format details beyond the schema's ISO 8601 specification.

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 the main WSF ferry routes operating on a given date, distinguishing itself from siblings by linking to ferry alerts and terminals.

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?

Explicitly explains when to use this tool vs alternatives: it notes that some alert route IDs may not appear, and directs users to wsdot_get_ferry_terminals for terminal IDs.

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 significant behavioral context beyond the readOnlyHint annotation: it explains the prerequisite of numeric terminal IDs, the date-dependent behavior (defaults to today, remainingOnly only applies to today), and the need to resolve terminal names via another tool. 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.

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

Three sentences, zero waste: first sentence states core purpose, second explains prerequisite, third clarifies parameter behavior. Every sentence earns its place. Information is front-loaded.

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 has 4 parameters, 2 required, no enums, and an output schema exists, the description covers all essential aspects: what it does, prerequisites, parameter guidance, and date handling. It also integrates with sibling tools effectively. No gaps.

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 the baseline is 3. However, the description adds value beyond the schema by explaining the context of using terminal IDs (requires numeric IDs, use sibling tool), clarifying the remainingOnly parameter's behavior (ignored for future dates), and providing the date default. This is genuinely helpful for correct invocation.

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 departure times for a specific WSF ferry route on a given date. It uses a specific verb ('Returns') and resource ('departure times for a specific WSF ferry route'), and distinguishes from sibling tools like wsdot_get_ferry_terminals and wsdot_get_ferry_routes.

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 tells when to use this tool (for ferry schedule queries) and provides crucial preconditions: requires numeric terminal IDs and suggests using wsdot_get_ferry_terminals to look them up. It also explains the behavior of the remainingOnly parameter, guiding the agent on when to set it (for 'next ferry' queries on today) and notes that for future dates all sailings are returned.

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?

No contradictions with readOnlyHint annotation. Description adds value by noting the list has ~22 terminals and rarely changes, aiding caching decisions. Discloses return fields (ID, name, abbreviation).

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?

Three sentences, each adding value: main action, usage guidance, and list characteristics. No fluff, front-loaded with 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?

Complete for a simple parameterless tool. Explains purpose, usage context, and return content. Output schema exists to detail structure, so description covers what's needed.

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?

No parameters in input schema, so description doesn't need to add parameter info. Baseline for 0 params is 4. Description provides context on why the tool is useful (resolving names to IDs).

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, abbreviations. It distinguishes itself from sibling tools by specifying its role in resolving terminal names to numeric IDs for use by schedule/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?

Explicitly says to call this first to resolve terminal names to IDs required by schedule and space tools. Also notes the list is small and rarely changes, implying caching. 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.

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

Annotations already declare readOnlyHint=true. The description adds that it returns data for all passes and lists the types of data, which is useful context. 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?

The description is two sentences: first defines purpose, second provides examples and use cases. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and an existing output schema, the description covers the tool's purpose, scope (all passes), and typical queries. It is complete for the given complexity.

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?

No parameters exist (schema coverage 100%), so baseline is 4. The description does not need to add parameter details.

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 road conditions for all Washington State mountain passes, listing specific data fields (status, weather, road condition, etc.) and giving examples of passes. It distinguishes from siblings as no other tool explicitly covers mountain pass conditions.

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 ('is the pass open?', traction law status, winter driving planning). It does not mention when not to use or alternatives, but the context is sufficient given the sibling 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?

Annotations declare readOnlyHint=true, matching the read-only nature. Description adds real-time context and explains the key field (DriveUpSpaceCount). No contradictions. Could mention data freshness or limitations but sufficient.

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-loaded with purpose. Second sentence provides specific guidance on filtering and interpreting results. 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 simple single parameter and low complexity, the description is complete. It covers the main use case, key field, and filtering option. Output schema exists but not needed.

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%, baseline 3. Description adds value by explaining that omitting the parameter returns all terminals and specifying the source for the ID (wsdot_get_ferry_terminals).

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 vehicle space at WSF terminals for upcoming sailings, with specific use cases ('will I make the ferry?'). It distinguishes from sibling tools like wsdot_get_ferry_schedule and wsdot_get_ferry_terminals.

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 explains when to use (for drive-up or reservable space), optionally filtering by terminal ID, and references wsdot_get_ferry_terminals for obtaining the ID. It lacks explicit 'when not to use' but provides clear context.

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 declare readOnlyHint=true, but the description adds valuable behavioral context: rates are 'time-banded' and 'change dynamically based on traffic conditions'. This explains the nature of the data beyond a simple static lookup, which is helpful for the agent to understand how to use the tool correctly.

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 a single sentence that front-loads the core purpose ('Returns current dynamic toll rates') and then lists the specific facilities. Every word adds value; no redundant or vague phrasing. It is appropriately sized for a zero-parameter tool.

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 that the tool has no parameters and an output schema exists (though not required), the description fully specifies what data is returned: dynamic toll rates for five specific facilities. It mentions time-banded and dynamic nature. For a read-only list tool, this is complete and sufficient for selection and 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 no parameters, so the description does not need to add parameter details. According to the guidelines, 0 parameters gives a baseline of 4. The description adds context about the scope of data (which facilities are included) but does not explain parameters because there are none. A solid score but not perfect since it could list affiliate facilities more concisely.

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 express lanes and tolled facilities, listing them explicitly (SR 99, SR 520 Bridge, I-405 Express Lanes, etc.). It distinguishes itself from sibling tools like ferry alerts or mountain passes by focusing solely on toll rates.

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 implicitly tells when to use this tool (when needing toll rates for WA express lanes). It does not explicitly mention when not to use it or provide alternatives, but given the tool's specificity and lack of parameters, usage context is clear. However, explicit exclusion of other rate types (e.g., ferry tolls) would be better.

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 indicate readOnlyHint=true. The description adds behavioral context by explaining the comparison logic (current vs. average) and how to interpret congestion (current exceeding average). 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?

The description is concise with two sentences that front-load the core purpose and efficiently provide usage guidance and filtering details.

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 (context: 'Has output schema: true'), the description sufficiently covers the tool's purpose, usage, and filtering behavior without needing to describe 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?

Schema coverage is 100% with a description for the route parameter. The description adds value by stating it's optional, case-insensitive, allows partial matching, and omitting returns all corridors.

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 current vs. average travel times for named WA highway corridors, listing specific routes like I-5 and I-405. This distinguishes it from sibling tools which focus on ferries, border waits, etc.

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 concrete usage examples like 'how congested is I-5?' and explains filtering by partial route name. While it doesn't explicitly state when not to use, the context is clear and no alternative among siblings is needed as they cover different domains.

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 declare readOnlyHint=true. Description adds critical behavioral traits: data lag of 30–60 seconds and null fields for inactive 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?

Three sentences, no fluff. Front-loaded with return data. Every sentence adds value.

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?

Provides extra context beyond annotations and output schema (lag, null fields). Completely sufficient for a zero-parameter 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?

No parameters defined. Schema coverage is 100% (none needed). Baseline score applies; description adds no param info but doesn't need to.

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 precisely states it returns real-time AIS positions, speed, heading, ETA, and dock status for active WSF vessels. Examples ('where is the ferry now?') clarify usage. No sibling overlaps.

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?

Explicitly provides use cases (vessel tracking, checking in-service status). Does not mention when not to use or alternatives, but sibling context implies differentiation (e.g., alerts, schedules).

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 declare readOnlyHint=true, so the description's behavioral contribution is limited. It adds context about alert types but doesn't disclose additional traits like auth needs or rate limits. The description does not contradict annotations.

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, front-loaded with purpose, then filter options. Every word is necessary and 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?

For a tool with 4 optional params, 100% schema coverage, and an output schema, the description sufficiently covers all aspects needed for selection and invocation, including filter range and omission behavior.

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 description adds valuable meaning beyond the schema: explains zero-padded format for stateRoute with examples (e.g., '005' for I-5) and mentions case-insensitive region matching. With 100% schema coverage, the description enriches parameter understanding.

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 active WA highway alerts with specific categories (incidents, construction, closures, restrictions). It distinguishes from siblings like wsdot_get_ferry_alerts by specifying highway alerts.

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 explains filtering by state route, region, or milepost range, and that omitting all filters returns all statewide alerts. It implicitly guides when to use it vs siblings, but lacks explicit when-not or alternative guidance.

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 significant behavioral context beyond the readOnlyHint annotation: it discloses copyright restrictions, that only metadata and URLs are returned (not image bytes), and the potential for hundreds of results with no filters. This fully informs the agent about the tool's 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?

Two concise sentences front-load the core purpose, then provide key behavioral notes and filtering options. Every sentence adds value 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?

Given the presence of an output schema (handling return values), the description fully covers all necessary context: what is returned, what is not, how to filter, and scale considerations. No gaps remain.

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?

With 100% schema description coverage, the schema already documents parameters. The description adds meaning by noting zero-padding for stateRoute, case-insensitivity for region, and milepost range filtering, providing examples that enhance usability beyond the schema.

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 camera locations, descriptions, and image URLs, and explicitly distinguishes itself by noting it returns only metadata and URLs, not image bytes. This verb+resource combination is specific and differentiates from sibling tools like ferry schedules or border waits.

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 guidance on filtering options (state route, region, milepost) and warns that omitting filters returns many results. It implicitly distinguishes from siblings (which are for different domains), but does not explicitly state when to use this tool vs alternatives.

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