Skip to main content
Glama

Bar Impact

bar_impact
Read-only

Compute impact stress, wave speed, contact duration, and yield for a bar striking a rigid wall end-on via exact St-Venant solution. Also returns force and rebound velocity.

Instructions

St-Venant bar impact, exact (NO solver): a uniform bar striking a rigid wall end-on. Face stress σ = ρ·c₀·v₀ with c₀ = √(E/ρ) — mass, area and length cancel, so only a slower strike or a softer/lighter material lowers it; contact lasts 2L/c₀ and the bar leaves stress-free at the strike speed (restitution 1). Past the yield velocity v_y = σ_y/(ρ·c₀) the face yields and a bilinear material (tangent_mpa) caps at σ_y + ρ·c_p·(v₀ − v_y), c_p = √(E_t/ρ). E and ρ from youngs_gpa/density_kg_m3 or a Materials-DB material (which also supplies yield). area_mm2 adds force_n. The closed-form twin impact_dynamics_submit is gated against; also the quick ceiling on what any strike at this speed can do to this material. Uniaxial-stress (slender bar) theory.

Returns {wave_speed_m_s, stress_mpa, elastic_stress_mpa, force_n, contact_duration_ms, rebound_velocity_m_s, yield_velocity_m_s, plastic, plastic_wave_speed_m_s, fidelity, band_pct, valid_range_ok, warnings, escalate_to}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
area_mm2No
materialNo
length_mmYes
yield_mpaNo
youngs_gpaNo
tangent_mpaNo
velocity_m_sYes
density_kg_m3No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.6

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation, disclosing detailed behavioral aspects: the exact formula, that mass/area/length cancel, contact duration, restitution, yield behavior, and the bilinear material cap. It also explains how material properties are sourced. This adds significant value beyond the annotations and gives the agent a precise understanding of the calculation's behavior.

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?

The description is a single dense paragraph, but every sentence carries essential information: physics, formulas, parameter sourcing, output list. It front-loads the core purpose and then expands. While it is longer than a minimal description, it is efficient and well-organized, with no filler.

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?

Given the tool's complexity (physics, material handling, yield) and lack of an output schema, the description is quite complete. It lists all returned fields, explains the theory, and mentions the twin solver. Minor gaps exist: it does not address error conditions, edge cases (e.g., very low velocity), or how 'fidelity' and 'band_pct' are determined, but these are secondary. Overall, it provides enough for an agent to invoke the tool correctly.

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

Parameters4/5

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

With schema description coverage at 0%, the description compensates by explaining key parameters: it mentions 'youngs_gpa'/'density_kg_m3' and the 'material' option, explains 'area_mm2' adds force, and discusses 'yield_mpa' and 'tangent_mpa' in the yield context. However, it does not explicitly describe 'velocity_m_s' and 'length_mm' (though they are implied by the physics) or clarify the exact role of 'tangent_mpa' beyond the yield cap. Overall it adds substantial meaning but not exhaustive coverage.

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

Purpose5/5

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

The description clearly states the tool's function: 'St-Venant bar impact, exact (NO solver): a uniform bar striking a rigid wall end-on.' It specifies the verb (compute impact) and resource (bar impact), and differentiates from the twin solver impact_dynamics_submit by calling it 'closed-form twin' and 'gated against'. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context by contrasting with impact_dynamics_submit ('closed-form twin ... gated against') and notes the theory ('Uniaxial-stress (slender bar) theory'). It implies this is a quick analytical alternative to a full solver, but does not explicitly state when to choose it over other impact tools (e.g., drop_impact) or list conditions where it should not be used. This is a clear but not exhaustive usage guideline.

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

Deploy Server

Other Tools