Multicalci exposes 9 process engineering calculation engines as MCP tools, so AI assistants call real standards-referenced code instead of estimating the arithmetic. All results are computed with iterative numerical methods (Newton-Raphson, quadrature) rather than approximations.
Tools include: pipe pressure drop (Darcy-Weisbach/Colebrook-White), control valve sizing for liquid and gas (IEC 60534-2-1), orifice flow (ISO 5167-2, Reader-Harris/Gallagher), gas Z-factor (Peng-Robinson), NPSH availa
Each tool targets a distinct engineering calculation: valve sizing for gas vs liquid, compressibility, NPSH, orifice flow, pipe friction, pump power, steam saturation, and tank volume. There is no functional overlap that would confuse an agent.
All tool names use lowercase snake_case and clearly indicate the calculation subject, but there is slight inconsistency in ordering (e.g., control_valve_size_gas vs gas_z_factor_pr) and inclusion of standards/suffixes (pr, iso5167, if97). The pattern is still predictable and readable.
With 9 tools, the server is well-scoped for a specialized engineering calculation toolkit. Each tool serves a distinct purpose without redundancy, and the count is comfortably within the ideal 3-15 range.
The toolset covers core fluid handling and thermodynamic calculations (valve sizing, pipe flow, pump selection, steam properties, tank geometry). Minor gaps exist, such as heat exchanger calculations or relief valve sizing, but the provided set covers common process engineering needs without major dead ends.
Size a control valve for gas or vapour service per IEC 60534-2-1 using the mass-flow form. Returns required Kv and Cv, pressure-drop ratio x, expansion factor Y and a choked-flow check against Fgamma*xT. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| xT | No | Pressure differential ratio factor xT (globe 0.72, ball 0.15) | |
| mass_flow_kgh | Yes | Gas mass flow rate, kg/h | |
| molecular_weight | No | Gas molecular weight, g/mol | |
| compressibility_Z | No | Compressibility factor Z at inlet | |
| inlet_pressure_bara | Yes | Upstream pressure P1, bar absolute | |
| inlet_temperature_k | No | Inlet temperature, K | |
| specific_heat_ratio | No | Ratio of specific heats gamma (Cp/Cv) | |
| outlet_pressure_bara | Yes | Downstream pressure P2, bar absolute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the outputs (Kv, Cv, x, Y, choked-flow check) and the calculation methodology (mass-flow form, IEC standard), adding meaningful behavioral context. It does not detail limitations or interpretation of the choking check, but overall is transparent for a calculation tool.
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 concise and front-loaded, with three sentences covering purpose, outputs, and a source credit. The 'Powered by multicalci.com' sentence provides little value for an AI agent, slightly reducing conciseness, but the overall structure is efficient.
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 an 8-parameter tool with no output schema, the description adequately states the return values and the calculation standard. It does not elaborate on edge cases (e.g., choked flow behavior) or interpret the results, but the description is sufficiently complete for invoking the tool correctly.
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 100%, so the baseline is 3. The description adds no parameter-specific details beyond the schema; it mentions the mass-flow form and outputs but does not elaborate on parameter meanings or relationships, so the schema already carries the weight.
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 'Size a control valve for gas or vapour service per IEC 60534-2-1' – a specific verb ('size') with a well-defined resource and scope. It distinguishes from the sibling 'control_valve_size_liquid' by explicitly naming gas/vapour service and specifies the calculation form.
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 clear context for gas/vapour service and references the relevant IEC standard, implying when to use it. However, it does not explicitly mention the alternative 'control_valve_size_liquid' or provide explicit exclusion conditions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Size a control valve for liquid service per IEC 60534-2-1 / ISA 75.01. Returns required Kv and Cv, choked-flow check (FF, dP limit) and cavitation index sigma with an assessment. Pressures in bar absolute. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| FL | No | Liquid pressure recovery factor (globe 0.9, ball 0.6, butterfly 0.7) | |
| flow_m3h | Yes | Liquid flow rate, m3/h | |
| density_kgm3 | No | Liquid density at flowing temperature, kg/m3 | |
| inlet_pressure_bara | Yes | Upstream pressure P1, bar absolute | |
| outlet_pressure_bara | Yes | Downstream pressure P2, bar absolute | |
| vapour_pressure_bara | No | Vapour pressure at flowing temperature, bar a | |
| critical_pressure_bara | No | Thermodynamic critical pressure, bar a |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses the key outputs (Kv, Cv, choked-flow check, cavitation index with assessment) and specifies that pressures are in bar absolute, which is critical for correct usage. It does not disclose error handling or limitations, but for a calculation tool this is adequate.
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 concise sentences deliver the purpose, key outputs, and unit convention with no filler. Front-loaded with the main task, then details, making it easy to scan.
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 tool's moderate complexity (7 parameters, no output schema), the description covers the essential return values and key unit constraints. It does not describe the exact format of the assessment or edge cases, but for a calculation tool with self-explanatory parameters, this is sufficient.
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 already provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds value by specifying that pressures are in bar absolute, removing ambiguity for the three pressure parameters. It also associates 'FF' and 'dP limit' with the choked-flow check, giving context to how the parameters are used.
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 uses the specific verb 'Size' with a clear resource ('control valve for liquid service') and explicitly references the applicable standards (IEC 60534-2-1 / ISA 75.01). This immediately distinguishes it from the sibling tool control_valve_size_gas.
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 clearly states the tool is for liquid service, which implies it should be used over the gas sibling. It does not explicitly name the alternative or provide when-not-to-use conditions, but the liquid-service qualifier is sufficient context for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-gas compressibility factor Z, molar volume, density and fugacity coefficient from the Peng-Robinson equation of state. When two roots exist the stable phase is chosen by minimum fugacity, not by root count. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| pressure_bara | Yes | Pressure, bar absolute | |
| temperature_c | Yes | Temperature, degC | |
| acentric_factor | Yes | Acentric factor omega | |
| molecular_weight | No | Molecular weight, g/mol | |
| critical_pressure_bara | Yes | Critical pressure Pc, bar absolute | |
| critical_temperature_k | Yes | Critical temperature Tc, K |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a valuable detail: when two roots exist, the stable phase is chosen by minimum fugacity, not root count. This reveals internal selection logic. It also lists outputs, giving the agent an idea of what to expect. It doesn't discuss side effects, but for a calculation tool this is less critical.
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 two sentences with the main purpose front-loaded. The first sentence is information-dense and efficient. However, the second sentence 'Powered by multicalci.com' is promotional and does not help an agent select or invoke the tool, slightly reducing conciseness. The structure is otherwise clear and scannable.
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?
The description explains the outputs and the key root-selection behavior, which is useful. However, it does not describe the output structure (no output schema exists), nor does it clarify the role of optional parameters like molecular_weight for computing density or molar volume. For a thermodynamic calculation tool with 6 parameters, this is a noticeable gap, but the core functionality is adequately covered.
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 input schema has 100% description coverage for all parameters, so the schema already provides units and meaning. The tool description does not add any further parameter-level context, such as typical ranges or dependencies (e.g., molecular_weight is optional and defaults to 28.96). Thus, it meets the baseline for high schema coverage but adds no extra value.
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 identifies the tool's outputs (Z, molar volume, density, fugacity coefficient) and the method (Peng-Robinson EOS), which distinguishes it from sibling tools that handle valve sizing, pipe flow, etc. However, it lacks an explicit verb like 'calculate' or 'compute', relying on the noun phrase to imply the action.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any alternative tools, limitations, or prerequisites. The only implied usage is from the tool's name and outputs, which is insufficient for an agent deciding between this and other engineering calculation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Net Positive Suction Head available for a centrifugal pump, broken down by component. Optionally compares against NPSHr and reports the margin with a Hydraulic Institute style assessment. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| density_kgm3 | No | Liquid density, kg/m3 | |
| static_head_m | Yes | Liquid level above pump centreline, m (negative for lift) | |
| friction_loss_m | No | Suction line friction and fitting losses, m | |
| npsh_required_m | No | Pump NPSHr from the curve, m (optional) | |
| vapour_pressure_bara | No | Vapour pressure at pumping temperature, bar a | |
| suction_pressure_bara | No | Absolute pressure on suction vessel surface, bar a |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses behavior by mentioning component breakdown and optional comparison with NPSHr, but does not explain what the output structure is or any safety/caveat details.
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 compact, but the sentence 'Powered by multicalci.com' is unnecessary filler that does not help an agent select or invoke the tool. The first two sentences are useful and front-loaded.
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 6 parameters and no output schema, the description partially explains the output ('broken down by component', 'reports margin') but does not specify the return format or calculation details. It is adequate for a simple calculator but leaves some ambiguity.
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 100%, so baseline is 3. The description adds minimal meaning beyond the schema, only hinting at the components involved but not detailing any parameter semantics or relationships.
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 calculates Net Positive Suction Head available for a centrifugal pump, with a component breakdown and optional NPSHr comparison. This distinguishes it from all siblings, which focus on other engineering calculations.
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 implies usage for NPSH calculations but does not explicitly state when to use this tool vs alternatives. No exclusions or alternative mentions are provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate mass flow through an orifice plate per ISO 5167-2 using the Reader-Harris/Gallagher discharge coefficient equation, solved iteratively against pipe Reynolds number. Supports corner, flange and D&D/2 taps, gas expansibility and permanent pressure loss. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| tap_type | No | Pressure tap arrangement | flange |
| pipe_id_mm | Yes | Pipe internal diameter D, mm | |
| fluid_state | No | Fluid state; gas/steam applies expansibility | liquid |
| density_kgm3 | No | Upstream fluid density, kg/m3 | |
| viscosity_cp | No | Dynamic viscosity, cP | |
| orifice_bore_mm | Yes | Orifice bore diameter d at flowing temperature, mm | |
| isentropic_exponent | No | Isentropic exponent kappa (gas/steam only) | |
| upstream_pressure_bara | No | Upstream static pressure, bar a (gas/steam only) | |
| differential_pressure_pa | Yes | Measured differential pressure, Pa | |
| downstream_pressure_bara | No | Downstream static pressure, bar a (gas/steam only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the calculation is 'solved iteratively against pipe Reynolds number' and notes support for gas expansibility and permanent pressure loss. It does not mention limitations or failure conditions, but the key behavior and scope are well conveyed.
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 three sentences, front-loaded with the core calculation, followed by supported options. It is efficient overall, though the final 'Powered by multicalci.com' sentence is non-functional noise for an AI agent and slightly reduces the score.
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?
This is a complex tool (10 parameters, iterative solver) with no output schema. The description covers the standard, equation, tap types, fluid states, and pressure loss, giving a solid operational picture. It does not explicitly state the return values (beyond 'mass flow') or constraints like beta ratio limits, but it is reasonably complete for selection and invocation.
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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds context about the iterative equation and the role of Reynolds number but does not explain parameter relationships or unit expectations beyond what the schema already provides.
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 a specific action: 'Calculate mass flow through an orifice plate per ISO 5167-2 using the Reader-Harris/Gallagher discharge coefficient equation'. It names the exact resource (orifice plate), standard, and method, and it is immediately distinguishable from sibling tools like control valve sizing or pipe pressure drop.
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 implies usage by specifying the calculation context (ISO 5167-2 orifice flow) and supported configurations ('corner, flange and D&D/2 taps, gas expansibility and permanent pressure loss'). It does not explicitly state when-not-to-use or name alternatives, but the scope is clear enough given the distinctive purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate friction pressure drop in a pipe using Darcy-Weisbach with the Colebrook-White friction factor. Handles laminar and turbulent flow, fitting losses by the K-method, and elevation change. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| flow_m3h | Yes | Volumetric flow rate, m3/h | |
| length_m | Yes | Straight pipe length, m | |
| diameter_mm | Yes | Pipe internal diameter, mm | |
| density_kgm3 | No | Fluid density, kg/m3 | |
| roughness_mm | No | Absolute pipe roughness, mm (CS 0.045, SS 0.015) | |
| viscosity_cp | No | Dynamic viscosity, cP | |
| fitting_k_total | No | Sum of fitting K factors | |
| elevation_change_m | No | Rise from inlet to outlet, m (negative if falling) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It explains the calculation model and scope, which is helpful, but it does not specify the output unit (e.g., Pa or bar), assumptions about fluid properties, or any limitations. The 'Powered by multicalci.com' provides no behavioral insight.
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 brief and front-loaded: the first sentence states the core calculation, the second expands scope. The only minor detractor is the promotional 'Powered by multicalci.com' clause, which is not essential but does not significantly hurt.
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?
The tool has 8 parameters and no output schema, so the description should provide more context about expected results and limitations. It describes the model but omits output units, applicable fluid types (e.g., single-phase incompressible), and any required validation. This leaves significant gaps for an AI agent selecting and invoking the 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?
The input schema already describes each parameter with 100% coverage. The description adds value by linking parameters (fitting_k_total, elevation_change_m) to the physical model (K-method, elevation term), and by mentioning flow regimes (laminar/turbulent) that clarify the role of viscosity and density. This contextualizes parameters beyond their simple definitions.
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 'Calculate friction pressure drop in a pipe' and specifies the method (Darcy-Weisbach with Colebrook-White). This distinguishes it from sibling tools like control valve sizing or pump power, making the purpose specific and unambiguous.
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 enumerates handled cases (laminar/turbulent flow, fitting losses, elevation change), which implicitly defines when to use it. However, it does not explicitly state when not to use it or mention alternative tools for different calculations, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pump hydraulic, shaft (brake) and motor input power from duty point, with the next standard IEC motor frame size at a 15 percent margin. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| head_m | Yes | Total differential head, m | |
| flow_m3h | Yes | Flow rate, m3/h | |
| density_kgm3 | No | Liquid density, kg/m3 | |
| pump_efficiency | No | Pump efficiency, percent | |
| motor_efficiency | No | Motor efficiency, percent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core calculation and the 15% margin behavior, but does not mention assumptions like default efficiencies, error handling, or return format. It is not contradictory but lacks depth.
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 concise and front-loaded, using one sentence to convey the primary function and the margin detail. The 'Powered by multicalci.com' clause is non-essential but brief, so it does not significantly detract.
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?
Without an output schema, the description should explain return values more explicitly. It names the calculated powers and motor frame size but omits units, exact output fields, or any edge-case behavior, making it partially incomplete for a calculation 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 description coverage is 100%, as every parameter has a description. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies despite the absence of parameter-level clarification in the description.
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 calculates hydraulic, shaft (brake) and motor input power from a duty point, and identifies the next standard IEC motor frame size with a 15% margin. This specific scope distinguishes it from sibling tools like valve sizing or pipe pressure drop.
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 implies use for pump power calculations but provides no explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives. The context suggests it is applicable for pump sizing tasks, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Water and steam saturation properties from the IAPWS-IF97 Region 4 equation. Give either temperature_c to get saturation pressure, or pressure_bara to get saturation temperature. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| pressure_bara | No | Saturation pressure, bar absolute (0.0061 to 220.64) | |
| temperature_c | No | Saturation temperature, degC (0.01 to 373.946) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only calculation by stating it derives properties from an equation, and it mentions the external service 'Powered by multicalci.com.' However, it does not explicitly state that it is non-destructive, requires no special permissions, or describe error/edge-case behavior. The simple nature of a property calculator partly excuses this, but more transparency would be beneficial.
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?
Two concise sentences front-load the purpose, then explain input modes. Every sentence earns its place with no filler. The 'Powered by' note is brief and adds relevant context.
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?
The tool is simple (2 parameters, no output schema, no nested objects). The description fully explains what the tool does, the exact inputs and their ranges, and the expected outputs (saturation pressure or temperature). It even names the governing equation. No significant information is missing for an engineer to invoke it correctly.
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 covers 100% of parameter descriptions, giving ranges for pressure and temperature. The description adds crucial semantics by stating the parameters are mutually exclusive alternatives and what each returns (saturation pressure vs temperature). This goes beyond the schema's factual range information, clarifying intended usage.
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 calculates water and steam saturation properties via the IAPWS-IF97 Region 4 equation, and explains the two modes: input temperature for pressure or input pressure for temperature. This specific verb+resource+scope distinguishes it from all sibling tools, which are for other engineering calculations like valve sizing or pressure drop.
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?
Explicit usage instructions are provided: 'Give either temperature_c to get saturation pressure, or pressure_bara to get saturation temperature.' This clarifies when to use the tool and how to invoke it. No explicit exclusions or alternative tool names are mentioned, but the sibling context makes the fit obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total and partial-fill volume of a cylindrical tank or pressure vessel with flat, hemispherical, 2:1 ellipsoidal, torispherical (ASME F&D) or conical heads. Horizontal or vertical. The torispherical head is integrated over the exact crown and knuckle profile rather than the usual approximation. Powered by multicalci.com.
| Name | Required | Description | Default |
|---|---|---|---|
| head_type | No | Head type on both ends | ellipsoidal_2_1 |
| diameter_m | Yes | Inside shell diameter, m | |
| orientation | No | Vessel orientation | vertical |
| density_kgm3 | No | Liquid density for mass output, kg/m3 (optional) | |
| cone_height_m | No | Conical head height, m (default = D/2) | |
| crown_radius_m | No | Torispherical crown radius L, m (ASME F&D default = D) | |
| liquid_level_m | No | Liquid level from the lowest inside point, m (optional) | |
| knuckle_radius_m | No | Torispherical knuckle radius r, m (ASME F&D default = 0.06 D) | |
| straight_length_m | Yes | Straight shell length, tangent to tangent, m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a valuable detail: torispherical heads are integrated over the exact crown and knuckle profile rather than approximated. However, it does not disclose output units, return format, or behavior when density is provided for mass output, which is a notable gap given no annotations.
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 first three sentences are concise and informative, covering purpose, orientations, and the special torispherical integration. The 'Powered by multicalci.com' sentence is filler with no operational value, slightly reducing efficiency.
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 9 parameters and no output schema, the description should clarify that density enables mass output and liquid_level enables partial-fill volumes. It does neither explicitly, nor does it state defaults for head type and orientation. It covers the main purpose and differentiator but leaves important behavior undocumented.
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 100%, so all parameters have descriptions. The description adds context for torispherical geometry (crown/knuckle) but does not explain parameter interactions or defaults beyond what schema already provides, earning a baseline score.
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 computes total and partial-fill volume of cylindrical tanks/pressure vessels with specific head types. It is distinct from all sibling tools (valve sizing, pressure drop, etc.), making its purpose unambiguous.
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?
While no explicit alternatives or exclusions are mentioned, the tool's unique purpose among siblings makes its usage context clear. It is evident this tool is for volume calculations, not fluid dynamics or component sizing, but explicit when-to-use guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
control_valve_size_gascontrol_valve_size_liquidgas_z_factor_prnpsh_availableorifice_flow_iso5167pipe_pressure_droppump_powersteam_saturation_if97tank_volumeClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
