Evaluate a list of rectangular member heights or plate thicknesses to check if they satisfy load and material requirements, without modifying the CAD model.
Evaluate an explicit finite list of rectangular-member heights or plate thicknesses. This is a deterministic scenario calculation and does not modify CAD.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| heightsMm | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds that the tool is deterministic and does not modify CAD, which reinforces and slightly extends the annotation profile. It does not disclose return behavior, error conditions, or how the extensive input object is processed.
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 short sentences with no wasted words. The main purpose is front-loaded, and the non-destructive nature is stated immediately afterward.
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 tool with a complex, deeply nested input schema, no output schema, and 0% schema description coverage, the description is too sparse. It omits explanation of the required input object, method choices, material/evidence requirements, and what the evaluation returns. An agent would need to reverse-engineer most of the call contract from the raw schema.
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 input schema is a large nested object with two top-level required parameters. The description mentions heights or plate thicknesses, which loosely maps to the heightsMm array, but it says nothing about the required 'input' object (goal, method, material, evidence, assignments, assumptions, binding). It does not compensate for the missing schema descriptions.
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 gives a specific verb and resource: 'Evaluate an explicit finite list of rectangular-member heights or plate thicknesses.' It also distinguishes the tool from CAD modification. However, it does not differentiate this tool from sibling strength or inspection tools such as plasticity_inspect_rectangular_member or plasticity_calculate_rectangular_strength_from_coupon_data.
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 explicit when-to-use guidance or alternatives. It only states that the tool is a deterministic scenario calculation and does not modify CAD, which is context but not usage direction. An agent must infer when to choose this tool over the numerous sibling strength tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.