Skip to main content
Glama

calculate_ground_track

Compute satellite ground track coordinates from orbital state vectors to visualize orbital paths over Earth's surface for flight planning and analysis.

Instructions

Calculate ground track from orbital state vectors.

Args: orbital_state: Orbital state (elements or state vector) duration_s: Duration for ground track calculation in seconds time_step_s: Time step for ground track points in seconds

Returns: JSON string with ground track coordinates

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orbital_stateYes
duration_sYes
time_step_sNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Registers the calculate_ground_track tool function with the FastMCP server using mcp.tool().
    mcp.tool(calculate_ground_track)
  • The main tool handler registered with MCP. It wraps the core implementation, handles input/output as JSON strings, and provides error handling and graceful degradation.
    def calculate_ground_track(
        orbital_state: dict, duration_s: float, time_step_s: float = 60.0
    ) -> str:
        """Calculate ground track from orbital state vectors.
    
        Args:
            orbital_state: Orbital state (elements or state vector)
            duration_s: Duration for ground track calculation in seconds
            time_step_s: Time step for ground track points in seconds
    
        Returns:
            JSON string with ground track coordinates
        """
        try:
            from ..integrations.orbits import calculate_ground_track as _ground_track
    
            result = _ground_track(orbital_state, duration_s, time_step_s)
    
            return json.dumps(result, indent=2)
    
        except ImportError:
            return "Ground track calculation not available - install orbital packages"
        except Exception as e:
            logger.error(f"Ground track error: {str(e)}", exc_info=True)
            return f"Ground track error: {str(e)}"
  • Core implementation of ground track calculation. Converts orbital state vectors to Earth-fixed latitude, longitude, altitude points, accounting for Earth rotation.
    def calculate_ground_track(
        orbit_states: list[StateVector], time_step_s: float = 60.0
    ) -> list[GroundTrack]:
        """
        Calculate ground track from orbit state vectors.
    
        Args:
            orbit_states: List of state vectors
            time_step_s: Time step between states (seconds)
    
        Returns:
            List of ground track points
        """
        ground_track = []
    
        for i, state in enumerate(orbit_states):
            r_vec = state.position_m
    
            # Convert to latitude/longitude
            r = vector_magnitude(r_vec)
            lat = math.asin(r_vec[2] / r)
    
            # Account for Earth rotation
            try:
                datetime.fromisoformat(state.epoch_utc.replace("Z", "+00:00"))
                t_since_epoch = i * time_step_s
                lon = math.atan2(r_vec[1], r_vec[0]) - OMEGA_EARTH * t_since_epoch
            except Exception:
                lon = math.atan2(r_vec[1], r_vec[0])
    
            # Normalize longitude to [-180, 180] degrees
            while lon > math.pi:
                lon -= 2 * math.pi
            while lon < -math.pi:
                lon += 2 * math.pi
    
            altitude = r - R_EARTH
    
            ground_track.append(
                GroundTrack(
                    latitude_deg=rad_to_deg(lat),
                    longitude_deg=rad_to_deg(lon),
                    altitude_m=altitude,
                    time_utc=state.epoch_utc,
                )
            )
    
        return ground_track
  • Dataclass defining the structure of ground track points returned by the tool.
    class GroundTrack:
        """Ground track point."""
    
        latitude_deg: float
        longitude_deg: float
        altitude_m: float
        time_utc: str
  • Dataclass for input state vectors used in ground track computation.
    class StateVector:
        """Position and velocity state vector."""
    
        position_m: list[float]  # Position vector [x, y, z] in meters
        velocity_ms: list[float]  # Velocity vector [vx, vy, vz] in m/s
        epoch_utc: str  # Epoch in UTC ISO format
        frame: str = "J2000"  # Reference frame
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the calculation process and return format but lacks critical details: it doesn't specify what coordinate system is used (e.g., geodetic, ECEF), whether the calculation accounts for Earth rotation or perturbations, what units the coordinates are in, or any limitations/assumptions. For a computational tool with complex orbital mechanics, this is insufficient.

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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose: the first states what the tool does, the next three document parameters, and the last specifies the return format. There's no redundant information, though it could benefit from more detailed explanations.

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

Completeness3/5

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

Given the tool's computational complexity (orbital mechanics), no annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (mentioned in Returns), the description lacks crucial context about coordinate systems, assumptions, and parameter formats. It meets minimum requirements by stating purpose and parameters but leaves significant gaps for proper tool invocation.

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

Parameters2/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 three parameters with brief labels but adds minimal semantic value: 'orbital_state' is described only as 'Orbital state (elements or state vector)' without explaining format differences; 'duration_s' and 'time_step_s' get basic units but no context about valid ranges or typical values. This doesn't adequately compensate for the complete lack of schema descriptions.

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

Purpose4/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 as 'Calculate ground track from orbital state vectors,' which is a specific verb+resource combination. It distinguishes from most siblings by focusing on orbital ground track calculation rather than other aerospace functions like trajectory analysis or coordinate transformations. However, it doesn't explicitly differentiate from potential similar tools like 'propagate_orbit_j2' which might have overlapping functionality.

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 any prerequisites, constraints, or comparison with sibling tools like 'propagate_orbit_j2' or 'orbital_rendezvous_planning' that might handle related orbital calculations. The user must infer usage from the purpose statement 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