Skip to main content
Glama

get_aircraft_performance

Calculate flight performance estimates for specific aircraft types by providing ICAO code, distance, and altitude to support aviation planning and operations.

Instructions

Get performance estimates for an aircraft type (requires OpenAP).

Args: aircraft_type: ICAO aircraft type code (e.g., 'A320', 'B737') distance_km: Flight distance in kilometers cruise_altitude_ft: Cruise altitude in feet

Returns: JSON string with performance estimates or error message

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aircraft_typeYes
distance_kmYes
cruise_altitude_ftNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function implementing the tool logic using OpenAP for aircraft performance estimation.
    def get_aircraft_performance(
        aircraft_type: str, distance_km: float, cruise_altitude_ft: float = 35000
    ) -> str:
        """Get performance estimates for an aircraft type (requires OpenAP).
    
        Args:
            aircraft_type: ICAO aircraft type code (e.g., 'A320', 'B737')
            distance_km: Flight distance in kilometers
            cruise_altitude_ft: Cruise altitude in feet
    
        Returns:
            JSON string with performance estimates or error message
        """
        if not OPENAP_AVAILABLE:
            return "OpenAP library is not available. Install with: pip install openap"
    
        try:
            performance = estimates_openap(aircraft_type, distance_km, cruise_altitude_ft)
            return json.dumps(performance, indent=2)
        except OpenAPError as e:
            return f"Performance estimation error: {str(e)}"
        except Exception as e:
            return f"Unexpected error: {str(e)}"
  • Registration of the get_aircraft_performance tool in the FastMCP server.
    mcp.tool(get_aircraft_performance)
  • Import of the get_aircraft_performance function necessary for registration.
    from .tools.core import (
        calculate_distance,
        get_aircraft_performance,
        get_system_status,
        plan_flight,
        search_airports,
    )
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'requires OpenAP' (implying authentication or API access needs) and describes the return as 'JSON string with performance estimates or error message' (indicating possible error states). However, it lacks details on rate limits, what specific performance metrics are included (e.g., fuel consumption, speed), whether this is a read-only operation, or any side effects. For a tool with no annotations, this is a significant gap in transparency.

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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured sections for 'Args' and 'Returns'. Each sentence earns its place by providing essential information without fluff. However, the 'Args' section could be more integrated into the flow rather than a separate block, and there's minor redundancy (e.g., 'JSON string' might be assumed from context).

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 complexity (3 parameters, no annotations, but has output schema), the description is partially complete. The output schema exists, so the description doesn't need to detail return values, which it acknowledges with 'JSON string with performance estimates or error message'. However, with no annotations and 0% schema coverage, it should do more to explain behavioral aspects like error handling or API constraints. It covers the basics but leaves gaps for a tool that likely involves external API calls.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics beyond the schema: it explains that 'aircraft_type' uses ICAO codes (e.g., 'A320', 'B737'), 'distance_km' is flight distance in kilometers, and 'cruise_altitude_ft' is cruise altitude in feet with an implied default (though not explicitly stated). This clarifies the units and formats, which the schema titles ('Aircraft Type', 'Distance Km', 'Cruise Altitude Ft') only hint at. However, it doesn't cover all nuances, such as valid ranges for parameters.

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: 'Get performance estimates for an aircraft type' with a specific verb ('Get') and resource ('performance estimates'). It distinguishes from siblings like 'plan_flight' or 'uav_energy_estimate' by focusing on aircraft performance rather than flight planning or energy estimation. However, it doesn't explicitly differentiate from all possible alternatives, such as 'get_airfoil_database' or 'get_propeller_database', which are also retrieval tools but for different data types.

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 provides implied usage context by stating 'requires OpenAP' (likely referring to an Open Aviation Performance API or similar), which suggests prerequisites. However, it doesn't explicitly say when to use this tool versus alternatives like 'plan_flight' (which might include performance aspects) or 'uav_energy_estimate' (which could overlap for UAVs). No clear exclusions or detailed alternatives are mentioned, leaving some ambiguity for the agent.

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