speed_convert

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as input validation, case sensitivity, or error handling. For example, it does not state whether empty strings or invalid units are accepted, or if the conversion is case-sensitive. This lack of transparency leaves the agent uncertain about edge cases.

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 extremely concise: two lines stating the purpose and a parameter list. It is front-loaded with the main action and units. Every word serves a purpose with no fluff or 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 lack of annotations and low schema coverage, the description is minimal. It covers the basic conversion but omits details like output format, error handling, or unit variants. However, since an output schema exists, the description need not explain return values, but it still misses behavioral context for a simple 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 coverage is 0%, so the description must compensate. It lists 'value — Speed value to convert.', 'from_unit — Source unit.', 'to_unit — Target unit.', which adds minimal clarity beyond the schema's property titles. However, it does not specify allowed values for from_unit/to_unit (e.g., exact strings, case sensitivity). This partial addition justifies a baseline 3.

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 purpose: 'Convert between speed units: km/h, mph, m/s, knots, ft/s.' It specifies the exact resource (speed units) and the action (convert), effectively distinguishing it from sibling tools like angle_convert or area_convert.

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 no guidance on when to use this tool versus alternatives. It lacks instructions on prerequisites, limitations, or scenarios where this tool is preferred. The only context is the list of units, but no when-to-use or when-not-to-use details.

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