Skip to main content
Glama

hohmann_transfer

Calculate Hohmann transfer orbit parameters to move spacecraft between two circular orbits. Input initial and final orbit radii to compute optimal transfer trajectory for orbital maneuvers.

Instructions

Calculate Hohmann transfer orbit parameters between two circular orbits.

Args: r1_m: Initial orbit radius in meters r2_m: Final orbit radius in meters

Returns: JSON string with transfer orbit parameters

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
r1_mYes
r2_mYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler function for hohmann_transfer. Wraps the core computation from integrations/orbits.py and returns formatted JSON string.
    def hohmann_transfer(r1_m: float, r2_m: float) -> str:
        """Calculate Hohmann transfer orbit parameters between two circular orbits.
    
        Args:
            r1_m: Initial orbit radius in meters
            r2_m: Final orbit radius in meters
    
        Returns:
            JSON string with transfer orbit parameters
        """
        try:
            from ..integrations.orbits import hohmann_transfer as _hohmann
    
            result = _hohmann(r1_m, r2_m)
    
            return json.dumps(result, indent=2)
    
        except ImportError:
            return "Transfer orbit calculation not available - install orbital packages"
        except Exception as e:
            logger.error(f"Hohmann transfer error: {str(e)}", exc_info=True)
            return f"Hohmann transfer error: {str(e)}"
  • Core implementation of Hohmann transfer calculation, computing delta-Vs, transfer time, and orbit parameters using two-body orbital mechanics formulas.
    def hohmann_transfer(r1_m: float, r2_m: float) -> dict[str, float]:
        """
        Calculate Hohmann transfer orbit parameters.
    
        Args:
            r1_m: Initial circular orbit radius (m)
            r2_m: Final circular orbit radius (m)
    
        Returns:
            Transfer parameters including delta-V requirements
        """
        # Transfer orbit semi-major axis
        a_transfer = (r1_m + r2_m) / 2
    
        # Velocities
        v1_circular = math.sqrt(MU_EARTH / r1_m)
        v2_circular = math.sqrt(MU_EARTH / r2_m)
    
        v1_transfer = math.sqrt(MU_EARTH * (2 / r1_m - 1 / a_transfer))
        v2_transfer = math.sqrt(MU_EARTH * (2 / r2_m - 1 / a_transfer))
    
        # Delta-V requirements (signed values)
        dv1 = v1_transfer - v1_circular  # Positive for prograde, negative for retrograde
        dv2 = v2_circular - v2_transfer  # Positive for prograde, negative for retrograde
        dv_total = abs(dv1) + abs(dv2)  # Total magnitude
    
        # Transfer time
        transfer_time = math.pi * math.sqrt(a_transfer**3 / MU_EARTH)
    
        return {
            "delta_v1_ms": dv1,
            "delta_v2_ms": dv2,
            "total_delta_v_ms": dv_total,
            "transfer_time_s": transfer_time,
            "transfer_time_h": transfer_time / 3600,
            "transfer_semi_major_axis_m": a_transfer,
        }
  • Registration of the hohmann_transfer tool with the FastMCP server.
    mcp.tool(hohmann_transfer)
  • Import of hohmann_transfer handler function into the FastMCP server module.
    from .tools.orbits import (
        calculate_ground_track,
        elements_to_state_vector,
        hohmann_transfer,
        orbital_rendezvous_planning,
        propagate_orbit_j2,
        state_vector_to_elements,
    )
Behavior2/5

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 mentions the calculation but doesn't describe what the tool actually does beyond that—no information about computational complexity, error handling, assumptions (e.g., two-body problem), or what happens with invalid inputs. The description is functional but lacks behavioral depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement followed by brief sections for arguments and returns. Every sentence earns its place: the first defines the tool, the second lists parameters, and the third describes the output. No wasted words, and information is front-loaded.

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 moderate complexity (orbital mechanics calculation), no annotations, and an output schema present, the description is reasonably complete. It covers the purpose, parameters, and output format. However, it lacks details on behavioral aspects and usage context, which would be beneficial for an AI agent to use it correctly in varied scenarios.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It lists the parameters (r1_m, r2_m) and specifies they are radii in meters, which adds meaning beyond the schema's generic titles. However, it doesn't explain constraints (e.g., positive values, r2 > r1), units beyond meters, or typical ranges, leaving gaps in parameter understanding.

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 specific action ('Calculate Hohmann transfer orbit parameters') and the resource ('between two circular orbits'), making the purpose immediately evident. It distinguishes itself from sibling tools like 'orbital_rendezvous_planning' or 'propagate_orbit_j2' by focusing specifically on Hohmann transfer calculations for circular orbits.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that orbits must be circular), limitations, or suggest other tools for different orbital scenarios (like elliptical transfers or rendezvous planning). The agent must infer usage from the purpose alone.

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/cheesejaguar/aerospace-mcp'

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