Skip to main content
Glama
IBM

Physics MCP Server

by IBM

calculate_inelastic_collision_3d

Calculate 3D collisions with energy loss using coefficient of restitution. Models realistic impacts like car crashes or ball bounces by conserving momentum while accounting for kinetic energy dissipation.

Instructions

Calculate 3D collision with coefficient of restitution.

Models realistic collisions where some kinetic energy is lost.
Coefficient of restitution (e) determines how much energy is retained.

Args:
    mass1: Mass of object 1 in kg
    velocity1: Velocity of object 1 [x, y, z] in m/s (or JSON string)
    mass2: Mass of object 2 in kg
    velocity2: Velocity of object 2 [x, y, z] in m/s (or JSON string)
    coefficient_of_restitution: e (0.0 = perfectly inelastic, 1.0 = perfectly elastic)

Returns:
    Dict containing:
        - final_velocity1: Final velocity [x, y, z] in m/s
        - final_velocity2: Final velocity [x, y, z] in m/s
        - initial_momentum: Total initial momentum [x, y, z]
        - final_momentum: Total final momentum [x, y, z]
        - initial_kinetic_energy: Total initial KE in Joules
        - final_kinetic_energy: Total final KE in Joules
        - energy_loss: Energy lost in Joules
        - energy_loss_percent: % of energy lost

Coefficient of restitution values:
    - e = 0.0: Perfectly inelastic (clay, putty) - objects stick
    - e = 0.5: Very inelastic (wet clay)
    - e = 0.7: Moderately elastic (basketball)
    - e = 0.9: Highly elastic (Super Ball)
    - e = 1.0: Perfectly elastic (ideal, no energy loss)

Tips for LLMs:
    - Momentum is always conserved (regardless of e)
    - Energy lost = (1 - e²) × initial KE in center-of-mass frame
    - Use e=1.0 for billiard balls, e=0.0 for car crashes

Example - Car crash:
    result = await calculate_inelastic_collision_3d(
        mass1=1500,  # kg
        velocity1=[20, 0, 0],  # 20 m/s east
        mass2=1200,  # kg
        velocity2=[-15, 0, 0],  # 15 m/s west
        coefficient_of_restitution=0.1  # very inelastic
    )
    # Massive energy loss, objects nearly stick together

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mass1Yes
velocity1Yes
mass2Yes
velocity2Yes
coefficient_of_restitutionNo
Behavior5/5

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

With no annotations provided, the description carries full burden and excels. It explains the physics behavior ('Momentum is always conserved'), provides the energy loss formula, gives practical examples (car crash), and details the return structure with 8 specific output fields. It fully discloses what the tool calculates and how it behaves.

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 well-structured with clear sections (purpose, args, returns, coefficient values, tips, example) but could be more concise. Some information (like the energy loss formula in tips) is valuable but makes it longer than minimal. Every sentence earns its place, but it's not maximally terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 3D physics calculation with 5 parameters and no output schema, the description is exceptionally complete. It covers purpose, parameters, return values, physics principles, usage examples, and practical guidance. No annotations exist, so the description provides all necessary context for proper tool invocation.

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?

With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each of the 5 parameters is clearly explained with units, format guidance (JSON string alternative), and the coefficient parameter gets extensive context with value ranges and material examples. The description adds substantial meaning beyond the bare schema.

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 purpose: 'Calculate 3D collision with coefficient of restitution' and distinguishes it from siblings like 'calculate_elastic_collision' by emphasizing realistic collisions where kinetic energy is lost. It specifies the physics domain (3D collisions) and key parameter (coefficient of restitution).

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool versus alternatives: 'Use e=1.0 for billiard balls, e=0.0 for car crashes' and gives specific coefficient examples for different materials. It distinguishes from elastic collision tools by focusing on inelastic scenarios where energy is lost.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IBM/chuk-mcp-physics'

If you have feedback or need assistance with the MCP directory API, please join our Discord server