CommercialBuses

check_cdl_requirement

Read-only

Whether a bus needs a commercial driver's license under US federal rules, which class (B or C), and which endorsements (passenger, school bus), from the passenger count, weight rating and whether it carries students. Returns a link to buses for sale in that size. Federal only; states can add rules.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "passengers": "<passengers>"
    },
    "name": "check_cdl_requirement"
  }
}

Input Schema

Name	Required	Description
`weight`	No	Gross vehicle weight rating, from the door-frame label. Default unknown.
`passengers`	Yes	Passenger seats, not counting the driver. Count each wheelchair position.
`carries_students`	No	true if it will carry students to or from school or school events.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover read-only/safe behavior, so the marginal bar is lower; the description adds real context: it discloses the rule basis (US federal CDL rules), the output shape (class B/C, endorsements), and an important limitation (federal only, states can add rules). The odd side effect of returning a bus-for-sale link is disclosed, though not explained.

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?

Two tight sentences, front-loaded with the question the tool answers and the outputs. The trailing 'Returns a link to buses for sale' sentence is slightly puzzling but earns a place by disclosing an unexpected return.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

For a read-only, single-purpose classifier with fully documented params and no output schema, this is nearly complete: rule basis, outputs, and federal-only limitation are all stated. Missing only explicit guidance on the state-law edge case and what the response looks like.

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 coverage is 100% and the parameter descriptions are already precise (seats excluding driver, wheelchair positions counted, weight from door-frame label). The description only restates that these inputs drive the result, adding no format or edge-case detail beyond the schema; baseline 3 applies.

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?

States a specific verb (check/classify) and resource (CDL requirement for a bus), plus the exact outputs: needs-CDL yes/no, class B or C, and endorsements. Clearly distinct from siblings like check_vehicle_rules or get_used_bus_prices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage (from passenger count, weight, and student carriage) but no explicit when-to-use or when-not, and no routing to the closest sibling check_vehicle_rules. The 'Federal only; states can add rules' caveat hints at scope limits but doesn't say what to do about states.

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

All CommercialBuses tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?