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

No annotations, so the description carries the full burden. It does disclose the dual output (bubble and dew in Fahrenheit), input pressure units (psig), and a certification precondition, but says nothing about error handling, valid refrigerant coverage, pressure bounds, or what the return actually looks like structurally.

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?

Front-loads the purpose, then adds the qualification note, example, and interpretation rule, all of which earn their place. Slightly dense and the stray line break after the example is cosmetic, but there is 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?

With no output schema and no annotations, the description steps up by describing both returned values (bubble and dew, in Fahrenheit) and giving a concrete call example. It is nearly sufficient for a two-parameter lookup; only refrigerant coverage and error behavior are left implicit.

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. The worked example pt_reverse("R-454B", 130) usefully conveys parameter order, the refrigerant string format, and the numeric pressure scale, but neither parameter's valid range or accepted naming conventions are documented.

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?

States a specific transformation (pressure in psig -> saturation temperature) with precise qualifiers: bubble and dew, Fahrenheit. This functionally distinguishes it from pt_lookup, but it never names that sibling or explains the direction contrast explicitly, so the differentiation must be inferred.

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 real domain guidance: use DEW for superheat work and BUBBLE for subcooling work on blends, plus an audience/qualification note (EPA 608, A2L). It does not explicitly say when to prefer this over pt_lookup or how it relates to the superheat/subcooling sibling tools, so it stops short of a full when-to-use/exclusion statement.

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