Skip to main content
Glama
IBM

Physics MCP Server

by IBM

check_equilibrium

Verify static equilibrium by checking if net force and net torque equal zero for a system of forces and positions.

Instructions

Check complete static equilibrium: ΣF = 0 and Στ = 0.

For static equilibrium, both force and torque must be balanced.

Args:
    forces: List of force vectors [[x,y,z], ...] in N (or JSON string)
    force_positions: Positions where forces applied [[x,y,z], ...] (or JSON string)
    pivot_point: Pivot point for torque calculation [x,y,z] (default [0,0,0])
    tolerance: Tolerance for equilibrium check (default 0.01)

Returns:
    Dict containing:
        - force_balanced: Whether ΣF = 0
        - torque_balanced: Whether Στ = 0
        - in_equilibrium: Whether system is in static equilibrium
        - net_force: Net force [x, y, z] in N
        - net_torque: Net torque [x, y, z] in N⋅m

Example - Beam with two forces:
    result = await check_equilibrium(
        forces=[[0, 100, 0], [0, -100, 0]],
        force_positions=[[1, 0, 0], [2, 0, 0]]
    )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forcesYes
force_positionsYes
pivot_pointNo
toleranceNo
Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly describes the tool's behavior: it checks both force and torque equilibrium, uses a default pivot point and tolerance, and returns a comprehensive dictionary with specific keys. It discloses the mathematical condition being evaluated and the return structure, though it doesn't mention error handling or computational limitations.

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 statement, parameter definitions, return values, and an example. Every sentence adds value, though the example could be slightly more concise. The information is front-loaded with the core purpose stated first.

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 tool with no annotations and no output schema, the description provides excellent coverage. It explains the tool's purpose, parameters, return values, and includes a practical example. The main gap is the lack of explicit error conditions or edge case handling, but overall it's quite complete for this physics calculation tool.

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 explanations. It clearly defines each parameter's purpose, format, units, and default values. The description adds essential meaning beyond the bare schema, explaining that forces are vectors in Newtons, positions are coordinates, and tolerance is for equilibrium checking.

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: 'Check complete static equilibrium: ΣF = 0 and Στ = 0.' It specifies the exact physics condition being verified and distinguishes it from sibling tools like 'check_force_balance' and 'check_torque_balance' by combining both force and torque equilibrium checks.

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?

The description implies usage for static equilibrium analysis but doesn't explicitly state when to use this tool versus alternatives like 'check_force_balance' or 'check_torque_balance' individually. It provides a clear context (static equilibrium checking) but lacks explicit guidance on tool selection among similar siblings.

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