PT Chart

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

With no annotations, the description carries the full burden. It usefully discloses a real behavioral quirk ('a bare psi is treated as psig') and a certification precondition (EPA 608/A2L). It does not say what happens if from_unit and to_unit cross families (e.g., psig to F), what precision/rounding is applied, or how invalid units are handled.

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 short sentences with the core conversion scope front-loaded, followed by the psi edge case and then the audience constraint. No filler, though the certification sentence is arguably a policy note rather than tool behavior.

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 3-required-param tool with no annotations and no output schema, the description covers supported units and one parsing edge case but leaves open the output shape (scalar vs object), cross-family conversion behavior, and failure modes. Adequate but with visible gaps for a tool an agent must call blind.

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 0% for all three parameters, so the description must compensate. It enumerates valid unit strings for from_unit/to_unit, which is genuinely valuable, and clarifies psi/psig ambiguity. It says nothing about the 'value' parameter's semantics (e.g., gauge vs absolute reference) or whether mixed-family conversions are legal input.

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 verb+resource (convert between pressure and temperature units) and enumerates the supported unit set (psig, psia, kpa, bar, F, C), which makes the tool's scope immediately clear. It does not distinguish itself from siblings like pt_lookup or pt_reverse, which also deal with pressure and temperature relationships, so an agent must infer the boundary.

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?

There is no statement of when to use this versus pt_lookup/pt_reverse, which is the key routing question in this toolset (unit conversion vs refrigerant PT-based conversion). The only contextual guidance is an audience restriction ('for certified HVAC technicians'), which is not usage guidance about the tool's role.

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 annotations are provided, so the description carries the burden. It makes clear this is a passive informational lookup rather than an action, and warns against misuse as a diagnostic. It doesn't explicitly state there are no side effects or that the answer is static, but for a zero-parameter info tool the risk is minimal.

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?

Short and front-loaded: the identity statement comes first, then the usage conditions and the exclusion. The line-broken formatting adds visual noise without adding content, but nothing is padded or repetitive.

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 parameterless, side-effect-free lookup with no output schema, the agent only needs to know what the tool is about and when to call it, both of which are covered. It could say slightly more about the shape of the response, but the gaps are minor given the tool's simplicity.

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 schema takes zero parameters, which is the baseline-4 case. The description adds no parameter guidance because none is needed, and it doesn't mislead about inputs.

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 a specific resource (information about CoolBooked, the AI appointment-booking connector) and explicitly negates a likely misread: 'This is NOT a diagnostic tool.' That negation cleanly separates it from the sibling 'diagnose' tool without requiring the agent to open either schema.

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 gives concrete trigger conditions -- 'call it when someone asks what CoolBooked is, how shop owners can try it, or how the free PT tools connect to paid bookings' -- and an explicit when-not (diagnostics). An agent can route on these cues alone.

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?

With no annotations, the description carries the full burden and does a decent job: it discloses the nature of the output (computed values plus a ranked checklist), the advisory-not-actionable posture, and an explicit refusal boundary around safety devices and venting. It does not say what happens with out-of-range or inconsistent readings, nor whether any state persists, which keeps it short of a 5.

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 purpose and output are front-loaded in the first sentence, and the safety/certification caveats, while longer, earn their place for a tool touching refrigerant handling. The trailing 'metering' line reads slightly like an afterthought appended to the paragraph rather than being integrated.

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 7-parameter tool with no annotations and no output schema, the description adequately conveys the diagnostic flow and advisory posture, and the psig/_f parameter names encode units. It is nonetheless incomplete on parameter expectations and edge-case behavior, which matters given six required inputs that determine correctness of the computed diagnosis.

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 0% across 7 parameters, so the description must compensate. It explains only 'metering' ('txv' default, or 'fixed' for fixed-orifice/piston systems), leaving refrigerant, suction_psig, head_psig, and the two line temperatures plus ambient undocumented beyond their self-evident names — no unit expectations, valid refrigerant naming, or expected ranges.

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 names a concrete verb+resource ('conversational diagnostic copilot' that takes field readings and returns computed superheat/subcooling plus a ranked 'check this first' list). This clearly distinguishes it from the sibling primitives superheat, subcooling, pt_lookup and pt_reverse, which return single measurements rather than a ranked diagnosis.

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 the intended audience (certified HVAC technicians, EPA 608 / A2L) and hard limits ('informational only', never how to defeat a safety device), which scopes use appropriately. However it never says when to pick diagnose over superheat/subcooling/pt_lookup, nor what conditions make the copilot the right call — usage is implied by the output description only.

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?

With no annotations, the description carries the full burden and does well: it discloses the return units (psig), that two values (bubble and dew) are returned, that they coincide for pure fluids, and that certification is a prerequisite. It omits error behavior for unrecognized refrigerants and any valid temperature/refrigerant ranges.

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-loaded with the core purpose, then example, then the operational bubble/dew guidance. Every sentence carries information, though the certification note sits between the example and the usage rules, slightly interrupting the flow of the most actionable content.

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?

No output schema exists, and the description adequately covers the return shape (psig, bubble and dew) and the special pure-fluid case. For a 2-parameter domain lookup this is nearly sufficient; the remaining gap is naming/range validation, which matters little since there is no error-handling context to convey.

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% (only bare titles), so the description must compensate: it specifies temp_f is in Fahrenheit and demonstrates the argument order and refrigerant string format via pt_lookup("R-454B", 45). It still does not state valid refrigerant naming conventions or a supported list, which leaves ambiguity for the agent.

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 verb (lookup) and resource (saturation pressure, bubble and dew, in psig) with explicit input units (Fahrenheit) plus a concrete call example. An agent immediately understands this is a PT chart lookup returning two pressure values, and the companion tool pt_reverse is implicitly the inverse operation.

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?

Gives real conditional guidance: bubble point for subcooling calculations, dew point for superheat calculations, and notes pure fluids show no glide so both values match. It also states the prerequisite audience (EPA 608 / A2L certified technicians). It does not explicitly name alternatives such as pt_reverse or the subcooling/superheat tools as the downstream consumers.

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 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.

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

With no annotations, the description carries the full burden; it discloses that output is informational only (no mutation or side effects), names the required certification context, and enumerates the returned content. It does not discuss latency, rate limits, or how unknown refrigerants are handled, but for a simple read-only reference tool this is solid disclosure.

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 short, front-loaded lines with no filler; the returned-field list is dense and useful. Slightly choppy line breaks and no mention of the input format keep it from a 5, but nothing is wasted.

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?

No output schema exists, but the description enumerates the return fields, so the agent knows what to expect. The prerequisite/audience note and the informational-only framing round out the picture; only the input parameter format is unaddressed.

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 0% and the single required parameter 'refrigerant' has no description, type detail, or format hint in the description either. The description enumerates output fields but says nothing about the expected input form (e.g., 'R-410A' vs '410A' vs a numeric ID), leaving the agent to guess the most important input detail.

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 resource (a refrigerant reference card) and enumerates exactly what fields it returns: GWP, ASHRAE safety class, composition, oil, glide, handling notes. It is clearly a lookup, distinguishable from siblings like pt_lookup or convert_units. It does not explicitly name an alternative for when a different refrigerant query is wanted, so it falls just short of 5.

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?

Gives audience and prerequisite context ('For certified HVAC technicians (EPA 608; A2L certification where required)') and flags 'Informational only', which implies it is not a calculation tool. However, it never says when to prefer this over pt_lookup, pt_reverse, or the other refrigerant-property siblings, so routing is left to inference.

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?

With no annotations, the description carries the full behavioral burden, and it delivers the methodologically critical disclosure that BUBBLE point is the saturation basis (not dew) for blended refrigerants, plus the EPA 608/A2L prerequisite and an expected output range. It still omits error behavior and output formatting details, so it is not complete.

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?

Short, front-loaded, and every fragment carries information: definition first, then safety prerequisite, then saturation methodology, then interpretation benchmark. Slightly clipped telegraphic phrasing but no wasted sentences.

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?

No output schema and no annotations, so the description must cover everything; 'Subcooling in Fahrenheit' does imply the return unit, but the accepted refrigerant values and failure modes for an invalid refrigerant string are unspecified. Adequate for a simple calculator, but not fully self-contained.

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 0%, and the description supplies units for two of three parameters (psig, F), which the schema lacks. The third and most error-prone parameter, the free-text 'refrigerant' string, is never explained - no accepted naming format and no valid list - which is a real gap for a 0%-coverage 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?

Names the exact quantity produced (subcooling in Fahrenheit) and both inputs with their units (head pressure in psig, liquid-line temperature in F). It is clearly distinct from the sibling 'superheat', though it never explicitly says so.

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?

Usage is implied by the domain framing and the 'Typical TXV target: 8-12F' benchmark, which tells the agent how to interpret a result. However, there is no explicit when-to-use guidance relative to 'superheat' or 'pt_lookup', and no statement of preconditions beyond the certification note.

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that the DEW point is used as the saturation basis (critical for blended refrigerants) and that the result is in Fahrenheit. It omits error behavior (invalid refrigerant, out-of-range inputs) and whether the refrigerant argument accepts trade names or only numeric designations.

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 short sentences, each carrying distinct information (output, inputs, audience, method, benchmark). The core purpose is front-loaded with 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?

For a small compute tool with no output schema and no annotations, the description covers the return value (Fahrenheit superheat), the computation basis, and a sanity-check range. It lacks only supported-refrigerant coverage and failure behavior, which keeps it short of complete.

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 0%, so the description must compensate for three undocumented parameters. It does clarify units for suction_psig (psig) and suction_line_f (F) and the saturation basis, but the refrigerant parameter's accepted values are never described, leaving a real gap.

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 computed quantity (superheat in Fahrenheit) and its exact inputs (suction pressure psig, suction-line temperature F). It is readily distinguishable from the sibling subcooling and pt_lookup tools, which compute different quantities.

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 audience and applicability guidance ('for certified HVAC technicians (EPA 608; A2L where required)') and an interpretive benchmark ('typical TXV target: 8-12F'). It does not explicitly name alternatives such as subcooling or pt_lookup or state when to prefer this over them, so it stops short of a 5.

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