Thermoprops

Solve a thermodynamics script

solve_worksheet

Read-only

Solves processes and whole cycles with CoolProp, written as a Thermoprops Worksheet script. Answers a table of the states, the printed results, errors by line, and a link that opens it solved with diagrams: give it to the user.

One statement per line, # comments: fluid R134a units celsius # or kelvin, imperial reference ASHRAE # zero of h, s: DEF, ASHRAE (textbook refrigerant tables), IIR, NBP 1: T = -10 °C, sat vapor # two properties; sat liquid is x = 0 2: from 1, compressed to P = 1.2 MPa, eta = 80% 3: P = P2, sat liquid 4: from 3, throttled to P = P1 COP = (h1 - h4) / (h2 - h1) print COP, T2 in °F, cp2 Processes: isentropic, compressed/expanded (eta), throttled, isobaric, isothermal, isochoric, isenthalpic, polytropic (n). Properties: T P h s x D v u cp cv mu k Pr Z a g; states show T P h s x v, print others. Fluids: Air, Ammonia, Argon, CarbonDioxide, CarbonMonoxide, Ethanol, Helium, Hydrogen, IsoButane, Isopentane, Methane, n-Butane, n-Pentane, n-Propane, Nitrogen, Oxygen, R1234yf, R1234ze(E), R125, R134a, R143a, R152A, R22, R245fa, R32, R404A, R410A, R507A, Toluene, Water. More syntax: language_reference.

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": {
      "script": "<script>"
    },
    "name": "solve_worksheet"
  }
}

Input Schema

Name	Required	Description	Default
`script`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing the response shape, including errors reported by line and a link that opens the solution with diagrams, plus the directive to hand the link to the user. This is meaningful output behavior in the absence of an output schema. It does not state failure modes such as invalid fluid names or convergence problems.

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?

Purpose and return value are front-loaded before any syntax detail, and the worked Rankine-style example is the most efficient way to convey the grammar. The property and fluid enumerations are dense but each token is functional for constructing a valid script. Some of this reference material overlaps language_reference, so it is slightly longer than strictly necessary.

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 complex tool taking one opaque DSL string with no output schema, the description covers input grammar and output contents adequately. Gaps remain around error recovery and the semantics of the returned link (expiry, whether it is public), but nothing essential to writing a working script is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single opaque script string, so the description must carry the entire burden and largely does: line-per-statement grammar, # comments, fluid/units/reference declarations, numbered state definitions, process keywords with eta and n, a property vocabulary, and a full fluid list. An agent can compose a valid script from this text alone, with only edge syntax deferred to language_reference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific action and domain: solving thermodynamic processes and whole cycles via a CoolProp/Thermoprops Worksheet script. It also states the return artifact (state table, printed results, per-line errors, solved link), which is well beyond a restatement of the name. It stops short of contrasting itself with the sibling fluid_state, so an agent must infer that a single-state lookup belongs elsewhere.

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?

Usage is only implied through the worked example and the closing pointer to language_reference for more syntax. There is no explicit statement of when to choose this over fluid_state or when a script is overkill, and no guidance on what to do when a script errors.

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

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