Skip to main content
Glama
cheesejaguar

Aerospace MCP

by cheesejaguar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Aerospace MCP - Flight Planning API & MCP Server

Python 3.11+ FastAPI OpenAP MCP Compatible NumPy GPU Ready License: MIT

A comprehensive aerospace research and flight planning service providing both HTTP API and Model Context Protocol (MCP) integration. Built with FastMCP for streamlined MCP server development. Features intelligent airport resolution, great-circle route calculation, aircraft performance estimation, atmospheric modeling, coordinate frame transformations, aerodynamic analysis, propeller performance modeling, rocket trajectory optimization, orbital mechanics calculations, and spacecraft trajectory planning for aerospace operations.

⚠️ SAFETY DISCLAIMER

THIS SOFTWARE IS FOR EDUCATIONAL, RESEARCH, AND DEVELOPMENT PURPOSES ONLY

  • NOT FOR REAL NAVIGATION: Do not use for actual flight planning or navigation

  • NOT CERTIFIED: This system is not certified by any aviation authority

  • ESTIMATES ONLY: Performance calculations are theoretical estimates

  • NO WEATHER DATA: Does not account for weather, NOTAMs, or airspace restrictions

  • NO LIABILITY: Authors assume no responsibility for any consequences of use

For real flight planning, always use certified aviation software and consult official sources including NOTAMs, weather reports, and air traffic control.

Related MCP server: Skyscanner MCP Server

🚀 Quick Start

Option 1: UV (Recommended)

# Install UV (fast Python package manager)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Clone and setup
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp
uv venv && source .venv/bin/activate  # Windows: .venv\Scripts\activate
uv sync

# Copy env and configure (optional but recommended)
cp .env.example .env
# Edit .env as needed (host/port/log level, optional LLM tools)

# Run HTTP server (package entrypoint)
uv run aerospace-mcp-http

# Alternatively (developer style)
uvicorn main:app --reload --host 0.0.0.0 --port 8080

# Test the API
curl "http://localhost:8080/health"

Option 2: Docker

git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp
docker build -t aerospace-mcp .
docker run -p 8080:8080 aerospace-mcp

# Test the API
curl "http://localhost:8080/health"

Option 3: MCP Client (Claude Desktop)

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "aerospace": {
      "command": "uv",
      "args": ["--directory", "/path/to/aerospace-mcp", "run", "aerospace-mcp"],
      "env": {
        "LLM_TOOLS_ENABLED": "true",
        "OPENAI_API_KEY": "your-openai-api-key-here"
      }
    }
  }
}

Note: The env section is optional and only needed if you want to enable the AI-powered agent tools for enhanced user experience.

MCP via CLI

# Start the MCP server (stdio)
uv run aerospace-mcp

# Start in SSE mode (optional)
uv run aerospace-mcp sse 0.0.0.0 8001

📋 Table of Contents

✨ Features

Core Capabilities

  • Airport Resolution: Intelligent city-to-airport mapping with 7,861 IATA airports worldwide

  • Route Planning: Great-circle distance calculation with geodesic precision

  • Performance Estimation: Aircraft-specific fuel and time calculations via OpenAP

  • Atmospheric Modeling: ISA atmosphere profiles with optional enhanced precision

  • Coordinate Transformations: ECEF, ECI, geodetic frame conversions for aerospace analysis

  • Multiple Interfaces: HTTP REST API and Model Context Protocol (MCP) support

  • Real-time Processing: Sub-second response times for flight planning requests

Space & Orbital Mechanics Capabilities

  • 🛰️ Orbital Elements & State Vectors: Convert between Keplerian elements and Cartesian state vectors

  • 🌍 Orbit Propagation: Numerical integration with J2 perturbations using RK4 method

  • 🗺️ Ground Track Computation: Calculate satellite ground tracks for mission planning

  • 🔄 Hohmann Transfers: Calculate optimal two-impulse orbital transfers

  • 🤝 Orbital Rendezvous: Plan multi-maneuver rendezvous sequences

  • 🎯 Trajectory Optimization: Genetic algorithms and particle swarm optimization

  • 📊 Uncertainty Analysis: Monte Carlo sampling for trajectory robustness assessment

  • 🚀 Lambert Problem: Two-body trajectory determination for given time-of-flight

Supported Operations

  • ✅ Airport search by city name or IATA code

  • ✅ Flight route planning with polyline generation

  • ✅ Aircraft performance estimation (37 aircraft models via OpenAP)

  • ✅ Fuel consumption and flight time calculations

  • ✅ Great-circle distance calculations

  • ✅ Multi-leg journey planning (plan_multi_leg_flight, 2-10 waypoints with aggregated totals)

  • ✅ Wind-aware flight planning (optional headwind-adjusted cruise speed, time, and fuel)

  • ✅ Aircraft database browsing and search (get_aircraft_database)

  • ✅ Unit conversions (length, speed, mass, pressure, temperature, angle)

  • ✅ Aircraft comparison analysis

  • ✅ Atmospheric profile calculation (ISA standard atmosphere)

  • ✅ Wind profile modeling (logarithmic/power law)

  • ✅ Coordinate frame transformations (ECEF, ECI, geodetic)

  • ✅ Wing aerodynamics analysis (VLM, lifting line theory)

  • ✅ Airfoil polar generation and database access

  • ✅ Aircraft stability derivatives calculation

  • ✅ Propeller performance analysis (BEMT)

  • ✅ UAV energy optimization and endurance estimation

  • ✅ Motor-propeller matching analysis

  • ✅ 3DOF rocket trajectory simulation with atmosphere integration

  • ✅ Rocket sizing estimation for mission planning

  • ✅ Launch angle optimization for maximum performance

  • ✅ Thrust profile optimization using gradient descent

  • ✅ Trajectory sensitivity analysis for design studies

  • ✅ System capability discovery and status reporting

  • ✅ Orbital mechanics calculations (Keplerian elements, state vectors, propagation)

  • ✅ Ground track computation for satellite tracking and visualization

  • ✅ Hohmann transfer planning for orbital maneuvers and mission design

  • ✅ Orbital rendezvous planning for spacecraft proximity operations

  • ✅ Trajectory optimization using genetic algorithms and particle swarm optimization

  • ✅ Monte Carlo uncertainty analysis for trajectory robustness assessment

  • ✅ Lambert problem solving for two-body trajectory determination

  • ✅ Porkchop plot generation for interplanetary transfer opportunity analysis

  • ✅ Optional SPICE integration with fallback to simplified ephemeris models

  • ✅ Density altitude calculation for performance planning

  • ✅ Airspeed conversions (IAS/CAS/EAS/TAS/Mach)

  • ✅ Stall speed calculation for different configurations

  • ✅ Weight and balance calculations with CG limits

  • ✅ Takeoff/landing performance distance and V-speeds

  • ✅ Fuel reserve calculation per FAR/ICAO regulations

  • ✅ Kalman filter state estimation for sensor fusion

  • ✅ LQR controller design for optimal control

Technical Features

  • 🚀 Fast: In-memory airport database for microsecond lookups

  • 🔧 Flexible: Pluggable backend system (currently OpenAP)

  • 📊 Accurate: Uses WGS84 geodesic calculations

  • 🌐 Standards: Follows ICAO aircraft codes and IATA airport codes

  • 🔒 Reliable: Comprehensive error handling and graceful degradation

  • 📚 Well-documented: Complete API documentation with examples

  • ⚡ Hardware Optimized: NumPy vectorization with CuPy GPU acceleration support

  • 🔄 Batch Processing: Vectorized operations for efficient bulk calculations

  • 🔍 Tool Discovery: Dynamic tool search for finding relevant tools from 47 specialized tools plus 2 discovery tools

💾 Installation

System Requirements

  • Python: 3.11+ (3.12+ recommended for best performance)

  • Memory: 512MB RAM minimum (1GB+ recommended)

  • Storage: 200MB free space

  • Network: Internet connection for initial setup

Method 1: UV Package Manager (Recommended)

UV is the fastest Python package manager and provides excellent dependency resolution:

# Install UV
curl -LsSf https://astral.sh/uv/install.sh | sh  # Linux/macOS
# Or: powershell -c "irm https://astral.sh/uv/install.ps1 | iex"  # Windows

# Clone repository
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp

# Create virtual environment
uv venv
source .venv/bin/activate  # Linux/macOS
# .venv\Scripts\activate     # Windows

# Install dependencies
uv add fastapi uvicorn[standard] airportsdata geographiclib pydantic python-dotenv
uv add openap  # Optional: for performance estimates
uv add mcp     # Optional: for MCP server functionality

# Install optional aerospace analysis dependencies
uv add --optional-dependencies atmosphere  # Ambiance for enhanced ISA
uv add --optional-dependencies space      # Astropy for coordinate frames
uv add --optional-dependencies all        # All optional dependencies

# Install development dependencies (optional)
uv add --dev pytest httpx black isort mypy pre-commit

# Verify installation
python -c "import main; print('✅ Installation successful')"

Method 2: Pip (Traditional)

# Clone repository
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp

# Create virtual environment
python -m venv .venv
source .venv/bin/activate  # Linux/macOS
# .venv\Scripts\activate     # Windows

# Upgrade pip
pip install --upgrade pip

# Install core dependencies
pip install fastapi uvicorn[standard] airportsdata geographiclib pydantic python-dotenv

# Install optional dependencies
pip install openap  # For performance estimates
pip install mcp     # For MCP server
pip install python-dotenv  # For loading .env in local/dev

# Install from pyproject.toml
pip install -e .

# Verify installation
python -c "import main; print('✅ Installation successful')"

Method 3: Docker

# Clone repository
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp

# Build image
docker build -t aerospace-mcp .

# Run container
docker run -d -p 8080:8080 --name aerospace-mcp aerospace-mcp

# Health check
curl http://localhost:8080/health

# View logs
docker logs aerospace-mcp

# Stop container
docker stop aerospace-mcp

Method 4: Conda/Mamba

# Create conda environment
conda create -n aerospace-mcp python=3.11
conda activate aerospace-mcp

# Clone repository
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp

# Install dependencies
conda install fastapi uvicorn pydantic
pip install airportsdata geographiclib openap mcp

# Verify installation
python -c "import main; print('✅ Installation successful')"

Troubleshooting Installation

Common Issues

OpenAP Installation Problems:

# Try these alternatives if OpenAP fails to install
pip install openap --no-cache-dir
pip install openap --force-reinstall
# Or install without OpenAP (performance estimates will be unavailable)

GeographicLib Issues:

# Install system dependencies (Ubuntu/Debian)
sudo apt-get install libproj-dev proj-data proj-bin

# Install system dependencies (macOS)
brew install proj

# Install system dependencies (Windows)
# Download from: https://proj.org/download.html

Import Errors:

# Verify your Python environment
python --version  # Should be 3.11+
pip list | grep -E "(fastapi|openap|airportsdata)"

# Test individual imports
python -c "import fastapi; print('FastAPI OK')"
python -c "import airportsdata; print('AirportsData OK')"
python -c "import openap; print('OpenAP OK')" || echo "OpenAP not available (optional)"

🎯 Usage Examples

HTTP API Examples

Basic Flight Planning

# Plan a simple flight
curl -X POST "http://localhost:8080/plan" \
  -H "Content-Type: application/json" \
  -d '{
    "depart_city": "San Francisco",
    "arrive_city": "New York",
    "ac_type": "A320",
    "cruise_alt_ft": 37000,
    "backend": "openap"
  }'

Airport Search

# Find airports by city
curl "http://localhost:8080/airports/by_city?city=Tokyo"

# Filter by country
curl "http://localhost:8080/airports/by_city?city=London&country=GB"

# Multiple results
curl "http://localhost:8080/airports/by_city?city=Paris"

Advanced Flight Planning

# Specify exact airports and aircraft mass
curl -X POST "http://localhost:8080/plan" \
  -H "Content-Type: application/json" \
  -d '{
    "depart_city": "Los Angeles",
    "arrive_city": "Tokyo",
    "prefer_depart_iata": "LAX",
    "prefer_arrive_iata": "NRT",
    "ac_type": "B777",
    "cruise_alt_ft": 39000,
    "mass_kg": 220000,
    "route_step_km": 100.0,
    "backend": "openap"
  }'

Python Client Examples

Simple Client

import requests
import json

class AerospaceClient:
    def __init__(self, base_url="http://localhost:8080"):
        self.base_url = base_url

    def plan_flight(self, departure, arrival, aircraft="A320", altitude=35000):
        """Plan a flight between two cities."""
        response = requests.post(f"{self.base_url}/plan", json={
            "depart_city": departure,
            "arrive_city": arrival,
            "ac_type": aircraft,
            "cruise_alt_ft": altitude,
            "backend": "openap"
        })
        return response.json()

    def find_airports(self, city, country=None):
        """Find airports in a city."""
        params = {"city": city}
        if country:
            params["country"] = country
        response = requests.get(f"{self.base_url}/airports/by_city", params=params)
        return response.json()

# Usage
client = AerospaceClient()

# Find airports
airports = client.find_airports("Sydney", "AU")
print(f"Sydney has {len(airports)} airports")

# Plan flight
plan = client.plan_flight("Sydney", "Melbourne", "B737")
print(f"Flight distance: {plan['distance_nm']:.0f} NM")
print(f"Flight time: {plan['estimates']['block']['time_min']:.0f} minutes")

Batch Processing

import asyncio
import aiohttp
from typing import List, Dict

async def plan_multiple_flights(flights: List[Dict]) -> List[Dict]:
    """Plan multiple flights concurrently."""
    async with aiohttp.ClientSession() as session:
        tasks = []
        for flight in flights:
            task = plan_single_flight(session, flight)
            tasks.append(task)

        results = await asyncio.gather(*tasks, return_exceptions=True)
        return results

async def plan_single_flight(session, flight_data):
    """Plan a single flight."""
    async with session.post(
        "http://localhost:8080/plan",
        json=flight_data
    ) as response:
        return await response.json()

# Example usage
flights_to_plan = [
    {"depart_city": "New York", "arrive_city": "London", "ac_type": "A330"},
    {"depart_city": "London", "arrive_city": "Dubai", "ac_type": "B777"},
    {"depart_city": "Dubai", "arrive_city": "Singapore", "ac_type": "A350"}
]

# Run the batch planning
results = asyncio.run(plan_multiple_flights(flights_to_plan))
for i, result in enumerate(results):
    if not isinstance(result, Exception):
        print(f"Flight {i+1}: {result['distance_nm']:.0f} NM, {result['estimates']['block']['time_min']:.0f} min")

Orbital Mechanics Examples

Python Examples

import requests

class OrbitalMechanicsClient:
    def __init__(self, base_url="http://localhost:8080"):
        self.base_url = base_url

    def plan_hohmann_transfer(self, r1_km, r2_km):
        """Calculate Hohmann transfer between two circular orbits."""
        response = requests.post(f"{self.base_url}/hohmann_transfer", json={
            "r1_m": r1_km * 1000,  # Convert to meters
            "r2_m": r2_km * 1000
        })
        return response.json()

    def propagate_satellite_orbit(self, elements, duration_hours):
        """Propagate satellite orbit with J2 perturbations."""
        response = requests.post(f"{self.base_url}/propagate_orbit_j2", json={
            "initial_state": elements,
            "time_span_s": duration_hours * 3600,
            "time_step_s": 300  # 5-minute steps
        })
        return response.json()

# Example usage
client = OrbitalMechanicsClient()

# Plan a GTO to GEO transfer
gto_alt = 200    # km (perigee)
geo_alt = 35786  # km (GEO altitude)

transfer = client.plan_hohmann_transfer(
    6378 + gto_alt,  # Earth radius + altitude
    6378 + geo_alt
)

print(f"Transfer Delta-V: {transfer['delta_v_total_ms']/1000:.2f} km/s")
print(f"Transfer Time: {transfer['transfer_time_h']:.1f} hours")

# Propagate ISS orbit for one day
iss_elements = {
    "semi_major_axis_m": 6793000,  # ~415 km altitude
    "eccentricity": 0.0001,
    "inclination_deg": 51.6,
    "raan_deg": 0.0,
    "arg_periapsis_deg": 0.0,
    "true_anomaly_deg": 0.0,
    "epoch_utc": "2024-01-01T12:00:00"
}

orbit_states = client.propagate_satellite_orbit(iss_elements, 24)
print(f"Propagated {len(orbit_states)} orbital states over 24 hours")

Trajectory Optimization Example

# Optimize a lunar transfer trajectory
def optimize_lunar_transfer():
    initial_trajectory = [
        {
            "time_s": 0,
            "position_m": [6700000, 0, 0],      # LEO
            "velocity_ms": [0, 7500, 0]
        },
        {
            "time_s": 86400 * 3,  # 3 days
            "position_m": [384400000, 0, 0],    # Moon distance
            "velocity_ms": [0, 1000, 0]
        }
    ]

    response = requests.post("http://localhost:8080/genetic_algorithm_optimization", json={
        "initial_trajectory": initial_trajectory,
        "objective": "minimize_delta_v",
        "constraints": {
            "max_thrust_n": 50000,
            "max_acceleration_ms2": 10
        }
    })

    result = response.json()
    print(f"Optimized Delta-V: {result['total_delta_v_ms']/1000:.2f} km/s")
    print(f"Flight Time: {result['flight_time_s']/86400:.1f} days")
    return result

optimized_trajectory = optimize_lunar_transfer()

# Generate porkchop plot for Mars mission planning
def plan_mars_mission():
    response = requests.post("http://localhost:8080/porkchop_plot_analysis", json={
        "departure_body": "Earth",
        "arrival_body": "Mars",
        "min_tof_days": 200,
        "max_tof_days": 300
    })

    analysis = response.json()

    if analysis["summary_statistics"]["feasible_transfers"] > 0:
        optimal = analysis["optimal_transfer"]
        print(f"Optimal Mars Transfer:")
        print(f"  Launch: {optimal['departure_date']}")
        print(f"  Arrival: {optimal['arrival_date']}")
        print(f"  C3: {optimal['c3_km2_s2']:.2f} km²/s²")
        print(f"  Flight Time: {optimal['time_of_flight_days']:.0f} days")
    else:
        print("No feasible transfers found in date range")

plan_mars_mission()

JavaScript/TypeScript Examples

interface FlightPlan {
  depart_city: string;
  arrive_city: string;
  ac_type: string;
  cruise_alt_ft?: number;
  backend: "openap";
}

class AerospaceAPI {
  constructor(private baseUrl: string = "http://localhost:8080") {}

  async planFlight(request: FlightPlan) {
    const response = await fetch(`${this.baseUrl}/plan`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(request),
    });

    if (!response.ok) {
      throw new Error(`API Error: ${response.statusText}`);
    }

    return await response.json();
  }

  async findAirports(city: string, country?: string) {
    const params = new URLSearchParams({ city });
    if (country) params.append("country", country);

    const response = await fetch(`${this.baseUrl}/airports/by_city?${params}`);
    return await response.json();
  }
}

// Usage
const api = new AerospaceAPI();

try {
  const plan = await api.planFlight({
    depart_city: "Boston",
    arrive_city: "Seattle",
    ac_type: "B737",
    cruise_alt_ft: 36000,
    backend: "openap"
  });

  console.log(`Flight planned: ${plan.distance_nm} NM`);
  console.log(`Estimated time: ${plan.estimates.block.time_min} minutes`);
} catch (error) {
  console.error("Flight planning failed:", error);
}

🏗️ Architecture

System Overview

graph TB
    Users[Users/Clients] --> API[FastAPI REST API]
    Users --> MCP[MCP Server]

    API --> Core[Core Services]
    MCP --> Core

    subgraph "Core Services"
        Airport[Airport Resolution]
        Route[Route Calculation]
        Perf[Performance Estimation]
    end

    subgraph "Data Sources"
        AirportDB[Airport Database<br/>7,861 IATA airports]
        OpenAP[OpenAP Models<br/>37 aircraft]
        Geodesic[GeographicLib<br/>WGS84 calculations]
    end

    Airport --> AirportDB
    Route --> Geodesic
    Perf --> OpenAP

Key Components

  1. FastAPI Application (main.py)

    • RESTful endpoints for HTTP clients

    • Auto-generated OpenAPI documentation

    • Request/response validation with Pydantic

  2. MCP Server (aerospace_mcp/fastmcp_server.py)

    • Model Context Protocol implementation via FastMCP

    • Tool-based interface for AI assistants

    • Async request handling

  3. Core Services

    • Airport Resolution: City → Airport mapping with intelligent selection

    • Route Calculation: Great-circle paths with polyline generation

    • Performance Estimation: OpenAP-based fuel and time calculations

  4. Data Layer

    • In-memory Airport Database: 7,861 IATA airports loaded at startup

    • OpenAP Integration: Aircraft performance models

    • GeographicLib: Precise geodesic calculations

Design Principles

  • Performance First: In-memory data structures for sub-millisecond lookups

  • Graceful Degradation: Works without optional dependencies

  • Type Safety: Full type hints and Pydantic validation

  • Extensible: Plugin architecture for new backends

  • Standards Compliant: ICAO, IATA, and OpenAP standards

  • Hardware Agnostic: NumPy/CuPy abstraction for CPU/GPU flexibility

🚀 FastMCP Migration

This project has been migrated from the traditional MCP SDK to FastMCP, providing significant improvements in developer experience and code maintainability.

What is FastMCP?

FastMCP is a high-level, Pythonic framework for building Model Context Protocol servers. It dramatically reduces boilerplate code while maintaining full MCP compatibility.

Migration Benefits

✅ 70% Less Code: Tool definitions went from verbose JSON schemas to simple Python decorators ✅ Better Type Safety: Automatic schema generation from type hints ✅ Cleaner Architecture: Modular tool organization across logical domains ✅ Improved Maintainability: Pythonic code that's easier to read and extend ✅ Full Compatibility: Same MCP protocol, works with all existing clients

Before vs After

Before (Traditional MCP SDK):

Tool(
    name="search_airports",
    description="Search for airports by IATA code or city name",
    inputSchema={
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "IATA code or city name"},
            "country": {"type": "string", "description": "Optional country filter"},
            "query_type": {"type": "string", "enum": ["iata", "city", "auto"]}
        },
        "required": ["query"]
    }
)

@server.call_tool()
async def handle_call_tool(name: str, arguments: dict):
    if name == "search_airports":
        return await _handle_search_airports(arguments)
    # ... 40+ more tool handlers

After (FastMCP):

@mcp.tool
def search_airports(
    query: str,
    country: str | None = None,
    query_type: Literal["iata", "city", "auto"] = "auto"
) -> str:
    """Search for airports by IATA code or city name."""
    # Implementation here

Architecture Improvements

The FastMCP refactoring introduced a modular architecture with tools organized by domain:

  • tools/core.py - Core flight planning (search, plan, distance, performance)

  • tools/atmosphere.py - Atmospheric modeling and wind analysis

  • tools/frames.py - Coordinate frame transformations

  • tools/aerodynamics.py - Wing analysis and airfoil polars

  • tools/propellers.py - Propeller BEMT and UAV energy analysis

  • tools/rockets.py - Rocket trajectory and sizing

  • tools/orbits.py - Orbital mechanics and propagation

  • tools/optimization.py - Trajectory optimization algorithms

Integration modules with NumPy vectorization:

  • integrations/_array_backend.py - NumPy/CuPy abstraction layer for GPU support

  • integrations/atmosphere.py - Vectorized ISA atmosphere calculations

  • integrations/aero.py - Vectorized aerodynamics computations

  • integrations/rockets.py - Vectorized trajectory integration

  • integrations/frames.py - Vectorized coordinate transformations

Compatibility Notes

  • Entry Point: Now uses aerospace_mcp.fastmcp_server:run

  • Dependencies: Includes fastmcp>=2.11.3 instead of raw mcp

  • Server Name: Still aerospace-mcp for client compatibility

  • All Tools: All 47 tools maintain exact same names and parameters

⚙️ Configuration (.env)

Both the HTTP server and MCP servers automatically load environment variables from a local .env (via python-dotenv).

  • AEROSPACE_MCP_MODE: http or mcp (Docker entrypoint switch)

  • AEROSPACE_MCP_HOST: Bind host for HTTP (default 0.0.0.0)

  • AEROSPACE_MCP_PORT: Port for HTTP (default 8080)

  • AEROSPACE_MCP_LOG_LEVEL: debug|info|warning|error (default info)

  • AEROSPACE_MCP_ENV: development|production (controls reload)

  • LLM_TOOLS_ENABLED: true|false to enable AI agent tools (default false)

  • OPENAI_API_KEY: Required if LLM tools are enabled

HTTP API hardening (the FastAPI app in main.py is a thin layer over aerospace_mcp/core.py):

  • CORS_ORIGINS: Comma-separated list of allowed origins; CORS is disabled when unset

  • RATE_LIMIT_RPM: Per-IP requests per minute (default 120, 0 disables rate limiting)

  • MAX_BODY_BYTES: Maximum accepted request body size (default 1 MiB)

Example .env:

AEROSPACE_MCP_MODE=http
AEROSPACE_MCP_HOST=0.0.0.0
AEROSPACE_MCP_PORT=8080
AEROSPACE_MCP_LOG_LEVEL=debug
LLM_TOOLS_ENABLED=false
# OPENAI_API_KEY=sk-...

⚡ Performance

Benchmarks

Operation

Response Time

Throughput

Memory Usage

Health Check

< 1ms

10,000+ req/sec

~5MB

Airport Search

1-5ms

1,000+ req/sec

~50MB

Flight Planning

200-500ms

5-10 req/sec

~100MB

Distance Calc

10-50ms

100+ req/sec

~50MB

Optimization Tips

  1. Route Resolution: Use larger route_step_km values for faster processing

  2. Caching: Implement client-side caching for repeated requests

  3. Batch Processing: Use async clients for multiple concurrent requests

  4. Memory: Increase available RAM for better OpenAP performance

Scaling Considerations

  • Horizontal Scaling: Stateless design allows multiple instances

  • Load Balancing: Standard HTTP load balancers work well

  • Database: Consider external database for airport data at scale

  • Caching: Add Redis for shared cache across instances

GPU Acceleration (CuPy)

The aerospace calculations are optimized using NumPy's vectorized operations, with a drop-in CuPy backend for GPU acceleration on CUDA-capable hardware.

Enabling GPU Acceleration

# In your code, before using aerospace functions:
from aerospace_mcp.integrations._array_backend import set_backend, get_backend_info

# Check available backends
print(get_backend_info())
# {'current_backend': 'numpy', 'numpy_available': True, 'cupy_available': True, ...}

# Switch to GPU (requires CuPy and CUDA)
set_backend('cupy')

# Switch back to CPU
set_backend('numpy')

Installing CuPy

# For CUDA 11.x
pip install cupy-cuda11x

# For CUDA 12.x
pip install cupy-cuda12x

# Auto-detect CUDA version
pip install cupy

Modules with GPU Support

The following integration modules support GPU acceleration via the array backend:

Module

Operations

Speedup (GPU vs CPU)

atmosphere.py

ISA calculations, wind profiles

10-50x for large batches

aero.py

Wing analysis, airfoil polars

5-20x for alpha sweeps

rockets.py

Trajectory integration, performance analysis

3-10x

frames.py

Coordinate transformations (batch)

20-100x for large datasets

Note: GPU acceleration provides the most benefit for batch operations with 1000+ data points. For single calculations, CPU (NumPy) is typically faster due to GPU transfer overhead.

📖 API Documentation

Interactive Documentation

When running the server, comprehensive API documentation is available at:

Core Endpoints

GET /health

Health check and system status.

Response:

{
  "status": "ok",
  "openap": true,
  "airports_count": 7861
}

GET /airports/by_city

Search airports by city name.

Parameters:

  • city (required): City name to search

  • country (optional): ISO country code filter

Example: GET /airports/by_city?city=London&country=GB

POST /plan

Generate complete flight plan.

Request Body:

{
  "depart_city": "San Francisco",
  "arrive_city": "New York",
  "ac_type": "A320",
  "cruise_alt_ft": 37000,
  "mass_kg": 65000,
  "route_step_km": 25.0,
  "backend": "openap"
}

Response: Complete flight plan with route polyline and performance estimates.

Error Handling

All endpoints return standard HTTP status codes:

  • 200: Success

  • 400: Bad Request (invalid parameters)

  • 404: Not Found (airport/city not found)

  • 501: Not Implemented (backend unavailable)

Error responses include detailed messages:

{
  "detail": "departure: IATA 'XYZ' not found."
}

🤖 MCP Integration

Supported MCP Clients

  • Claude Desktop: Native integration

  • VS Code Continue: Plugin support

  • Custom Clients: Standard MCP protocol

Available Tools

Tool

Description

Parameters

search_airports

Find airports by IATA or city

query, country, query_type

plan_flight

Complete flight planning (optional wind-aware estimates)

departure, arrival, aircraft, route_options, wind

plan_multi_leg_flight

Multi-leg journeys through 2-10 waypoints with aggregated totals

waypoints, aircraft

get_aircraft_database

Browse/search available OpenAP aircraft types

search

convert_units

Length/speed/mass/pressure/temperature/angle conversions

value, from_unit, to_unit

calculate_distance

Great-circle distance

origin, destination, step_km

get_aircraft_performance

Performance estimates

aircraft_type, distance_km, cruise_altitude

get_atmosphere_profile

ISA atmosphere conditions

altitudes_m, model_type

wind_model_simple

Wind profile calculation

altitudes_m, surface_wind_mps, model

transform_frames

Coordinate transformations

xyz, from_frame, to_frame, epoch_iso

geodetic_to_ecef

Lat/lon to ECEF conversion

latitude_deg, longitude_deg, altitude_m

ecef_to_geodetic

ECEF to lat/lon conversion

x, y, z

wing_vlm_analysis

Wing aerodynamics analysis (VLM)

geometry, alpha_deg_list, mach

airfoil_polar_analysis

Airfoil polar generation

airfoil_name, alpha_deg_list, reynolds, mach

calculate_stability_derivatives

Stability derivatives calculation

geometry, alpha_deg, mach

propeller_bemt_analysis

Propeller performance (BEMT)

geometry, rpm_list, velocity_ms, altitude_m

uav_energy_estimate

UAV endurance and energy analysis

uav_config, battery_config, mission_profile

get_airfoil_database

Available airfoil coefficients

None

get_propeller_database

Available propeller data

None

rocket_3dof_trajectory

3DOF rocket trajectory simulation

geometry, dt_s, max_time_s, launch_angle_deg

estimate_rocket_sizing

Rocket sizing for mission requirements

target_altitude_m, payload_mass_kg, propellant_type

optimize_launch_angle

Launch angle optimization

geometry, objective, angle_bounds

optimize_thrust_profile

Thrust profile optimization

geometry, burn_time_s, total_impulse_target, n_segments, objective

trajectory_sensitivity_analysis

Parameter sensitivity analysis

base_geometry, parameter_variations, objective

get_system_status

System health and capabilities

None

elements_to_state_vector

Convert orbital elements to state vector

elements

state_vector_to_elements

Convert state vector to orbital elements

state_vector

propagate_orbit_j2

Propagate orbit with J2 perturbations

initial_state, time_span_s, time_step_s

calculate_ground_track

Calculate satellite ground track

orbit_states, time_step_s

hohmann_transfer

Calculate Hohmann transfer orbit

r1_m, r2_m

orbital_rendezvous_planning

Plan orbital rendezvous maneuvers

chaser_elements, target_elements

genetic_algorithm_optimization

Trajectory optimization using GA

initial_trajectory, objective, constraints

particle_swarm_optimization

Trajectory optimization using PSO

initial_trajectory, objective, constraints

monte_carlo_uncertainty_analysis

Monte Carlo trajectory uncertainty analysis

trajectory, uncertainty_params, num_samples

porkchop_plot_analysis

Generate porkchop plot for interplanetary transfers

departure_body, arrival_body, departure_dates, arrival_dates, min_tof_days, max_tof_days

search_aerospace_tools

Search for tools by name, description, or functionality

query, search_type, max_results, category

list_tool_categories

List all available tool categories with counts

None

lambert_problem_solver

Solve Lambert's problem for orbital transfers

r1_m, r2_m, tof_s, direction, central_body

density_altitude_calculator

Calculate density altitude from pressure altitude and temperature

pressure_altitude_ft, temperature_c

true_airspeed_converter

Convert between IAS/CAS/EAS/TAS/Mach

speed_value, speed_type, altitude_ft, temperature_c

stall_speed_calculator

Calculate stall speeds for different configurations

weight_kg, wing_area_m2, cl_max_clean, cl_max_landing

weight_and_balance

Calculate aircraft weight and CG position

basic_empty_weight_kg, fuel_kg, payload_items

takeoff_performance

Calculate takeoff distances and V-speeds

weight_kg, pressure_altitude_ft, temperature_c, wind_kts

landing_performance

Calculate landing distances and approach speeds

weight_kg, pressure_altitude_ft, temperature_c, runway_condition

fuel_reserve_calculator

Calculate required fuel reserves per regulations

regulation, trip_fuel_kg, cruise_fuel_flow_kg_hr

kalman_filter_state_estimation

State estimation using Kalman filter

initial_state, measurements, process_noise

lqr_controller_design

Design LQR optimal controller

A_matrix, B_matrix, Q_matrix, R_matrix

Claude Desktop Setup

  1. Open Claude Desktop Settings

  2. Add server configuration:

{
  "mcpServers": {
    "aerospace": {
      "command": "uv",
      "args": ["--directory", "/path/to/aerospace-mcp", "run", "aerospace-mcp"]
    }
  }
}

  1. Restart Claude Desktop

  2. Test with: "Search for airports in Tokyo"

Tool Discovery

With 47 specialized aerospace tools available (plus 2 discovery tools), the MCP server includes a tool search tool following Anthropic's guide for dynamic tool discovery:

# Search by natural language
search_aerospace_tools("atmospheric pressure altitude")
# Returns: get_atmosphere_profile, wind_model_simple, ...

# Search by regex pattern
search_aerospace_tools("(?i)orbit", search_type="regex")
# Returns: propagate_orbit_j2, elements_to_state_vector, hohmann_transfer, ...

# Filter by category
search_aerospace_tools("calculate", category="orbits")
# Returns only orbital mechanics tools matching "calculate"

# List all categories
list_tool_categories()
# Returns: core, atmosphere, frames, aerodynamics, propellers, rockets, orbits, gnc, performance, optimization, agents

Available categories:

  • core: Flight planning, airports, distance, aircraft performance

  • atmosphere: ISA profiles, wind modeling

  • frames: Coordinate transformations (ECEF, ECI, geodetic)

  • aerodynamics: Wing analysis, airfoil polars, stability derivatives

  • propellers: BEMT analysis, UAV energy estimation

  • rockets: 3DOF trajectory, sizing, launch optimization

  • orbits: Orbital elements, propagation, transfers, rendezvous, Lambert solver

  • optimization: GA, PSO, Monte Carlo, porkchop plots

  • gnc: Kalman filter state estimation, LQR controller design

  • performance: Density altitude, airspeed conversion, stall speeds, W&B, takeoff/landing

  • agents: LLM-powered tool selection and data formatting

Deferred Tool Loading

For applications with many tools, aerospace-mcp supports deferred tool loading to keep context windows efficient. When using the Anthropic API with MCP, configure your mcp_toolset to defer loading of all tools except the discovery tools:

{
  "tools": [
    {
      "type": "tool_search_tool_regex_20251119",
      "name": "tool_search_tool_regex"
    },
    {
      "type": "mcp_toolset",
      "mcp_server_name": "aerospace-mcp",
      "default_config": {
        "defer_loading": true
      },
      "configs": {
        "search_aerospace_tools": { "defer_loading": false },
        "list_tool_categories": { "defer_loading": false }
      }
    }
  ]
}

This configuration:

  1. Loads discovery tools immediately (search_aerospace_tools, list_tool_categories)

  2. Defers all other tools until Claude searches for them

  3. Automatically expands tool_reference blocks from search results into full definitions

When Claude needs a specific tool, it uses search_aerospace_tools which returns tool_reference blocks:

{
  "tool_references": [
    { "type": "tool_reference", "tool_name": "hohmann_transfer" },
    { "type": "tool_reference", "tool_name": "propagate_orbit_j2" }
  ]
}

The API automatically expands these references into full tool definitions, keeping context efficient while providing access to all 47 tools.

VS Code Continue Setup

Add to your config.json:

{
  "mcpServers": [
    {
      "name": "aerospace-mcp",
      "command": "uv",
      "args": ["run", "aerospace-mcp"],
      "workingDirectory": "/path/to/aerospace-mcp"
    }
  ]
}

🛠️ Development

Development Setup

# Clone and setup
git clone https://github.com/cheesejaguar/aerospace-mcp.git
cd aerospace-mcp

# Create development environment
uv venv
source .venv/bin/activate
uv add --dev pytest httpx black isort mypy pre-commit

# Install pre-commit hooks
pre-commit install

# Run development server
uvicorn main:app --reload --log-level debug

Testing

# Run all tests
pytest

# Run with coverage
pytest --cov=. --cov-report=html

# Run specific test file
pytest tests/test_plan.py -v

# Run tool-specific tests
pytest tests/tools/ -v

Code Quality

# Format code
black . && isort .

# Type checking
mypy main.py aerospace_mcp/

# Linting
ruff check .

# Pre-commit (runs all checks)
pre-commit run --all-files

Project Structure

aerospace-mcp/
├── main.py                 # FastAPI application
├── aerospace_mcp/          # MCP server implementation
│   ├── __init__.py
│   ├── fastmcp_server.py  # FastMCP server entry point
│   ├── core.py            # Shared business logic
│   ├── tools/             # MCP tool definitions
│   │   ├── core.py        # Flight planning tools
│   │   ├── atmosphere.py  # Atmospheric modeling tools
│   │   ├── aerodynamics.py # Wing & airfoil analysis
│   │   ├── frames.py      # Coordinate transformations
│   │   ├── rockets.py     # Rocket trajectory tools
│   │   ├── orbits.py      # Orbital mechanics tools
│   │   ├── propellers.py  # Propeller analysis tools
│   │   ├── optimization.py # Trajectory optimization
│   │   ├── gnc.py         # GNC tools (Kalman filter, LQR)
│   │   ├── performance.py # Aircraft performance tools
│   │   ├── agents.py      # LLM-powered agent tools
│   │   └── tool_search.py # Tool discovery and search
│   └── integrations/      # Backend computation modules
│       ├── _array_backend.py # NumPy/CuPy abstraction (GPU support)
│       ├── atmosphere.py  # Vectorized ISA calculations
│       ├── aero.py        # Vectorized aerodynamics
│       ├── frames.py      # Vectorized coordinate transforms
│       ├── rockets.py     # Vectorized trajectory integration
│       ├── orbits.py      # Orbital mechanics computations
│       └── propellers.py  # Propeller BEMT analysis
├── app/                   # Alternative FastAPI structure
│   ├── __init__.py
│   └── main.py
├── tests/                 # Test suite
│   ├── conftest.py
│   ├── test_airports.py
│   ├── test_plan.py
│   ├── test_fastmcp.py
│   ├── test_integrations_*.py  # Integration module tests
│   └── tools/             # Tool-specific tests
│       ├── test_tools_performance.py  # Performance tools tests
│       ├── test_tools_gnc.py          # GNC tools tests
│       └── test_tools_lambert.py      # Lambert solver tests
├── docs/                  # Documentation
│   ├── API.md
│   ├── ARCHITECTURE.md
│   ├── INTEGRATION.md
│   ├── QUICKSTART.md
│   ├── DEPLOYMENT.md
│   └── MCP_INTEGRATION.md
├── pyproject.toml         # Project configuration
├── requirements.txt       # Dependencies
├── Dockerfile            # Docker configuration
├── docker-compose.yml    # Multi-service setup
└── README.md             # This file

🤝 Contributing

We welcome contributions! Please see CONTRIBUTING.md for detailed guidelines.

Quick Contributing Guide

  1. Fork & Clone

    git clone https://github.com/yourusername/aerospace-mcp.git
cd aerospace-mcp

  2. Setup Development Environment

    uv venv && source .venv/bin/activate
uv add --dev pytest httpx black isort mypy

  3. Make Changes

    • Add features or fix bugs

    • Write tests for new functionality

    • Update documentation as needed

  4. Test & Format

    pytest
black . && isort .
mypy main.py

  5. Submit Pull Request

    • Clear title and description

    • Reference any related issues

    • Ensure CI/CD checks pass

Areas for Contribution

  • New Aircraft Support: Add more aircraft types to OpenAP

  • Weather Integration: Add weather data sources

  • Route Optimization: Wind-optimal routing beyond the built-in multi-leg planner (plan_multi_leg_flight)

  • UI/Frontend: Web interface for flight planning

  • Database Backend: PostgreSQL/MongoDB integration

  • Performance: Optimization and caching improvements

  • GPU Optimization: Extend CuPy support to additional modules

  • Vectorization: Improve NumPy vectorization coverage

📚 Documentation

Complete Documentation

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

Third-Party Acknowledgments

🆘 Support & Community

Getting Help

  • GitHub Issues: Bug reports and feature requests

  • GitHub Discussions: Questions and community support

  • Documentation: Comprehensive guides in /docs

  • Examples: Code examples and tutorials

Community

  • Discord: WIP for real-time chat

Professional Support

For enterprise support, consulting, or custom development:

⭐ Star this repository if you find it useful!

Built with ❤️ for the aviation and software development communities.

Available Tools

46 tools
airfoil_polar_analysisA

Generate airfoil polar data (CL, CD, CM vs alpha) using database or advanced methods.

Args: airfoil_name: Airfoil name (e.g., 'NACA2412', 'NACA0012') reynolds_number: Reynolds number mach_number: Mach number alpha_range_deg: Optional angle of attack range, defaults to [-10, 20] deg

Returns: Formatted string with airfoil polar data (CL, CD, CM, L/D vs. alpha).

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
airfoil_nameYes
reynolds_numberNo
mach_numberNo
alpha_range_degNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries full behavioral disclosure. It discloses that errors are returned as formatted strings, not thrown, and mentions 'database or advanced methods' but does not elaborate on computational cost, side effects, or whether the tool is read-only. This provides basic but incomplete 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 relatively concise: a one-sentence purpose followed by structured Args/Returns. It front-loads the key action. Minor redundancy could be removed, but overall it is efficiently structured.

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 complexity (4 parameters, output schema exists), the description covers purpose, parameters, returns format, and error handling. However, it lacks details like the source of 'advanced methods', typical use cases, or computational intensity, which would make it more complete for agent decision-making.

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%, but the description adds an 'Args' section explaining each parameter with examples (e.g., 'NACA2412' for airfoil_name) and defaults (e.g., alpha_range_deg defaults to [-10,20] deg). This adds significant meaning beyond the raw schema, though there is a slight discrepancy with the schema default of null for alpha_range_deg.

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 'Generate airfoil polar data (CL, CD, CM vs alpha) using database or advanced methods', providing a specific verb ('generate'), resource ('airfoil polar data'), and the coefficients involved. It distinguishes from sibling tools like 'get_airfoil_database' (retrieval) and 'wing_vlm_analysis' (3D wing analysis) by focusing on 2D polar generation.

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 does not provide explicit guidance on when to use this tool versus alternatives like 'get_airfoil_database' or 'wing_vlm_analysis'. While it implies usage for generating polar data, it lacks criteria for selection, exclusions, or prerequisites, leaving the agent to infer usage context.

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

calculate_distanceA

Calculate great circle distance between two points.

Args: lat1: Latitude of first point in degrees lon1: Longitude of first point in degrees lat2: Latitude of second point in degrees lon2: Longitude of second point in degrees

Returns: JSON string with distance in km and NM, plus initial/final bearings.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
lat1Yes
lon1Yes
lat2Yes
lon2Yes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It explains the output format (JSON with km and NM plus bearings) and error handling (returns formatted strings, no exceptions). However, it does not disclose assumptions like Earth radius or formula used.

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?

Description is well-structured with Args, Returns, and Raises sections. Every sentence is informative, no fluff.

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 tool's simplicity and the presence of an output schema, the description covers purpose, all parameters, return format, and error handling. It is complete for its context.

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 coverage is 0%, so description must add value. The description lists the parameters by name (lat1, lon1, etc.) but adds no additional detail beyond what the schema provides (e.g., valid ranges, units). Baseline of 3 is appropriate.

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 purpose: 'Calculate great circle distance between two points.' It uses a specific verb (calculate) and resource (distance), and distinguishes itself from sibling tools which cover different aerospace calculations.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for great circle distance, but does not state when other distance methods might be preferred.

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

calculate_ground_trackA

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 latitude/longitude coordinates.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
orbital_stateYes
duration_sYes
time_step_sNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior4/5

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

Explicitly describes error handling ('errors returned as formatted strings') and return format (JSON string). Since no annotations provided, the description effectively communicates read-only nature and safety profile.

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?

Structured with Args, Returns, Raises sections. Each sentence serves a purpose; no redundancy or fluff.

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?

Covers purpose, parameters, return type, and error behavior. Output schema exists, so return details are sufficient. Could mention typical usage or coordinate format but not essential.

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 coverage is 0%, but description adds meaning: clarifies orbital_state can be elements or state vector, and provides units for duration and time step. Lacks constraints or examples.

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?

Clear verb 'calculate' and resource 'ground track' from orbital state vectors. Implicitly distinct from sibling tools like 'propagate_orbit_j2' but lacks explicit differentiation.

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?

No guidance on when to use this tool versus alternatives such as 'propagate_orbit_j2' or 'plan_flight'. Description only states what it does, not context.

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

calculate_stability_derivativesA

Calculate basic longitudinal stability derivatives for a wing.

Args: wing_config: Wing configuration with keys: - span_m: Wing span in meters - chord_root_m: Root chord in meters - chord_tip_m: Tip chord in meters (optional) - sweep_deg: Quarter-chord sweep (optional, default 0) - dihedral_deg: Dihedral angle (optional, default 0) - twist_deg: Tip twist (optional, default 0) - airfoil_root: Root airfoil name (optional, default 'NACA2412') - airfoil_tip: Tip airfoil name (optional) flight_conditions: Flight conditions with keys: - alpha_deg: Reference angle of attack (optional, default 2.0) - mach: Mach number (optional, default 0.2)

Returns: JSON string with stability derivatives: - CL_alpha: Lift curve slope (dCL/dalpha) [1/rad] -- rate of lift change with angle of attack. Positive for conventional aircraft. - CM_alpha: Pitching moment slope (dCM/dalpha) [1/rad] -- must be negative for static longitudinal stability (nose-down restoring moment). - CL_alpha_dot: Unsteady lift derivative due to rate of alpha change. - CM_alpha_dot: Unsteady pitching moment derivative (pitch damping).

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
wing_configYes
flight_conditionsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

The description discloses error handling (returns formatted strings, no exceptions), output structure (JSON string with derivative definitions), and the nature of the calculation. With no annotations, it provides sufficient behavioral context, though it omits potential limitations or side effects.

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-organized with Args, Returns, Raises sections and is front-loaded with purpose. While slightly verbose in repeating derivative definitions, it remains clear and structured, earning its length.

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 no annotations, the description covers inputs, outputs, and error behavior adequately. It explains nested object structures and includes defaults, though it could mention more about the derivation method or assumptions. Overall, it equips the agent to use the tool correctly.

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?

Despite 0% schema description coverage, the description extensively details each parameter with keys, types, defaults, and optional fields (e.g., 'span_m: Wing span in meters', 'alpha_deg: Reference angle of attack (optional, default 2.0)'). This compensates fully for the sparse schema.

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 it calculates basic longitudinal stability derivatives for a wing, specifying the scope and output. However, it does not explicitly distinguish from sibling tools like wing_vlm_analysis, but the purpose is still specific and actionable.

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 lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, ideal scenarios, or when other tools might be more appropriate, leaving the agent without decision support.

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

density_altitude_calculatorA

Calculate density altitude from pressure altitude and temperature.

Density altitude is the altitude in the standard atmosphere at which the air density equals the actual air density at the given conditions. Essential for aircraft performance calculations.

Args: pressure_altitude_ft: Pressure altitude in feet temperature_c: Outside air temperature in Celsius dewpoint_c: Optional dewpoint for humidity correction

Returns: Formatted string with density altitude calculation results including air density, density ratio (sigma), pressure ratio (delta), and ISA deviation.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
pressure_altitude_ftYes
temperature_cYes
dewpoint_cNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description bears full burden. Describes inputs, output format (formatted string), and error handling (errors returned as strings). Missing side effects or computational limits.

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?

Well-structured with a brief opening, definition, and docstring-style Args/Returns/Raises. Front-loaded with core purpose, though Returns section is slightly verbose.

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?

Covers purpose, parameters, output (formatted string with specific values), and error handling. Output schema exists, so return values are partly defined. Lacks output units and validity ranges.

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?

Schema description coverage is 0%, but description adds units and meaning for all three parameters: pressure_altitude_ft in feet, temperature_c in Celsius, dewpoint_c optional for humidity correction. Goes well beyond 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?

Clearly states the tool calculates density altitude from pressure altitude and temperature, with a definition and significance. Distinct from siblings like stall_speed_calculator.

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?

Mentions essential for aircraft performance calculations but does not specify when to use vs alternatives or exclusion conditions. No guidance on when not to use.

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

ecef_to_geodeticA

Convert ECEF coordinates to geodetic (lat/lon/alt) coordinates.

Args: x_m: X coordinate in meters y_m: Y coordinate in meters z_m: Z coordinate in meters

Returns: JSON string with geodetic latitude (deg), longitude (deg), and altitude (m).

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
x_mYes
y_mYes
z_mYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

The description discloses the conversion action, input parameters with units, return format (JSON with lat/lon/alt), and error handling (returns formatted strings). However, it lacks important behavioral details like the reference ellipsoid (e.g., WGS84) and precision, which are relevant for coordinate transformations.

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 concise and well-structured with clear sections (Args, Returns, Raises). Every sentence serves a purpose, no fluff.

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 simplicity (3 parameters, no nested objects), the description covers inputs, outputs, and error handling. The presence of an output schema reduces the need to detail return structure, though missing reference ellipsoid is a minor gap.

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 explaining each parameter (x_m: X coordinate in meters, etc.), adding units and meaning beyond the schema names. This is highly valuable for correct usage.

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 explicitly states the tool converts ECEF coordinates to geodetic (lat/lon/alt) coordinates. It clearly identifies the verb 'Convert' and the resource 'ECEF to geodetic', and is easily distinguishable from sibling tools like geodetic_to_ecef.

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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., transform_frames). Usage is implied by the name and description, but no context or exclusions are given.

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

elements_to_state_vectorA

Convert orbital elements to state vector in J2000 frame.

Args: orbital_elements: Dict with orbital elements (semi_major_axis_m, eccentricity, etc.)

Returns: JSON string with position [x,y,z] in meters and velocity [vx,vy,vz] in m/s in the J2000 inertial frame.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
orbital_elementsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It mentions no direct exceptions but returns errors as formatted strings, which is useful. However, it does not disclose if the operation is read-only, requires authentication, or has side effects.

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 structured as a docstring with Args, Returns, and Raises sections. It is informative without being verbose, but the Returns section could be more concise since it essentially repeats the purpose.

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?

The description covers the return format (JSON string with position and velocity in J2000 frame) and error handling. Given the complexity of a conversion tool with a single nested parameter, it is fairly complete, though it could explicitly mention the coordinate frame in the Returns.

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?

The input schema has one parameter 'orbital_elements' as an object with no property definitions (0% schema coverage). The description adds examples like 'semi_major_axis_m, eccentricity, etc.', which provides some meaning, but it's still vague and does not list all expected fields or their types.

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 converts orbital elements to a state vector in the J2000 frame. It uses specific verb ('Convert') and resource ('orbital elements to state vector'), and is distinct from its inverse sibling 'state_vector_to_elements'.

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?

No explicit guidance on when to use this tool versus alternatives like 'state_vector_to_elements' or other orbital tools. The description lacks context for ideal usage scenarios or prerequisites.

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

estimate_rocket_sizingA

Estimate rocket sizing requirements for target altitude and payload.

Args: target_altitude_m: Target altitude in meters payload_mass_kg: Payload mass in kg propellant_type: Propellant type ('solid' or 'liquid') design_margin: Design margin factor

Returns: JSON string with sizing estimates including propellant mass, dry mass, total mass, and structural dimensions.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: Sizing uses the Tsiolkovsky rocket equation (ideal rocket equation): delta_V = Isp * g0 * ln(m_initial / m_final) Rearranged to solve for propellant mass: m_prop = m_final * (exp(delta_V / (Isp * g0)) - 1) where Isp is specific impulse and g0 = 9.80665 m/s^2.

ParametersJSON Schema
NameRequiredDescriptionDefault
target_altitude_mYes
payload_mass_kgYes
propellant_typeNosolid
design_marginNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It discloses the use of the ideal rocket equation, states that no exceptions are raised directly (errors are returned as strings), and describes the calculation methodology. It could mention that the tool is read-only, but overall it is transparent.

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 Args, Returns, Raises, and Note sections. The inclusion of the full Tsiolkovsky equation adds value but slightly increases length. Each sentence serves a purpose.

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 complexity (four parameters, physics-based calculation) and the presence of an output schema, the description covers inputs, output format, and methodology. It lacks explicit constraints (e.g., positive values) but is otherwise complete.

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?

Schema description coverage is 0%, but the description's 'Args' section provides explicit meanings for all four parameters, including defaults for propellant_type and design_margin. This fully compensates for the schema's lack of descriptions.

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 begins with 'Estimate rocket sizing requirements for target altitude and payload,' clearly stating the verb (estimate), resource (rocket sizing), and input conditions. It distinguishes from sibling tools like rocket_3dof_trajectory or optimize_launch_angle by focusing on mass and dimension estimation.

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 the governing equation (Tsiolkovsky) but offers no explicit guidance on when to use this simplified model versus alternatives like trajectory simulation. It lacks when-not-to-use advice or comparisons with sibling tools.

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

format_data_for_toolA

Help format data in the correct format for a specific aerospace-mcp tool.

Uses GPT-5-Medium to analyze the user's requirements and raw data, then provides the correctly formatted parameters for the specified tool.

Args: tool_name: Name of the aerospace-mcp tool to format data for user_requirements: Description of what the user wants to accomplish raw_data: Any raw data that needs to be formatted (optional)

Returns: Formatted JSON string with the correct parameters for the tool, or a JSON error object if the tool is not found or LLM call fails.

Raises: No exceptions are raised directly; errors are returned as formatted strings or JSON error objects.

ParametersJSON Schema
NameRequiredDescriptionDefault
tool_nameYes
user_requirementsYes
raw_dataNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

Without annotations, the description reveals key behaviors: uses GPT-5-Medium for formatting, returns JSON strings or error objects, and does not raise exceptions directly. It does not mention potential latency or costs of the LLM call, but covers the core functionality.

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 a clear docstring format (Args/Returns/Raises). It is mostly concise, though the opening sentence is somewhat redundant with the docstring.

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 no annotations, the description covers the tool's purpose, parameters, and return format adequately for an agent to decide when to use it. It explains the meta-tool nature relative to sibling tools, though more details on LLM behavior could enhance completeness.

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?

The description's Args section adds meaning beyond the schema: tool_name as the target tool name, user_requirements as user intent, raw_data as optional raw data. This compensates for the 0% schema coverage.

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 formats data for another aerospace-mcp tool using GPT-5-Medium. It specifies the verb 'format' and the resource 'data for a specific aerospace-mcp tool', distinguishing it from siblings that perform direct calculations or analyses.

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 when raw data or requirements need formatting for an aerospace tool, but does not explicitly state when not to use it or provide alternatives. Context suggests it is a helper tool, but no direct exclusion criteria are given.

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

fuel_reserve_calculatorA

Calculate required fuel reserves per aviation regulations.

Args: regulation: Regulatory framework - "FAR_91", "FAR_121", "JAR_OPS", or "ICAO" trip_fuel_kg: Planned trip fuel in kg cruise_fuel_flow_kg_hr: Cruise fuel flow rate in kg/hr flight_time_min: Planned flight time in minutes alternate_fuel_kg: Fuel to fly to alternate airport in kg holding_altitude_ft: Expected holding altitude for reserve calculations

Returns: Formatted string with fuel reserve breakdown per the selected regulation, including contingency, alternate, and final reserve components.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
regulationYes
trip_fuel_kgYes
cruise_fuel_flow_kg_hrYes
flight_time_minYes
alternate_fuel_kgNo
holding_altitude_ftNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses return format (formatted string with components) and error handling (errors returned as formatted strings). For a read-only calculator, this is transparent, though no explicit statement about side effects.

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 a well-structured docstring with purpose, args, returns, and raises. It is concise with no unnecessary information, and the purpose 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?

The description covers inputs, outputs, and error handling. With 6 parameters and an output schema (not visible but indicated), it is largely complete. However, specifics on how each regulation affects calculations could enhance completeness.

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 has 0% description coverage, but the description includes an Args section with brief explanations for all parameters (e.g., 'trip_fuel_kg: Planned trip fuel in kg'). This adds meaning beyond the schema titles.

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 'Calculate required fuel reserves per aviation regulations.' This provides a specific verb and resource, and the tool is distinct from siblings which are other aerospace calculations.

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 gives a clear context (aviation regulations) but does not provide explicit guidance on when to use this tool vs alternatives. Usage is implied but no exclusions or alternative tools are mentioned.

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

genetic_algorithm_optimizationA

Optimize spacecraft trajectory using genetic algorithm.

Args: optimization_problem: Problem definition (objective, constraints, variables) ga_parameters: Optional GA parameters (population_size, generations, etc.)

Returns: JSON string with optimization results including best solution found, convergence history, and final objective value.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: The GA operates on a population of candidate solutions through: 1. Selection: Tournament or roulette-wheel selection of parents. 2. Crossover: Combining parent chromosomes (e.g., single-point or uniform crossover) to produce offspring that inherit traits from both. 3. Mutation: Random perturbation of offspring genes with probability p_mutation to maintain diversity and avoid premature convergence. Each generation evaluates fitness, selects the best, and breeds the next generation until convergence or max generations reached.

ParametersJSON Schema
NameRequiredDescriptionDefault
optimization_problemYes
ga_parametersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description explains the GA process (selection, crossover, mutation), error handling, and return structure (JSON with best solution, convergence history). This provides good behavioral insight beyond basic functionality.

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?

Description is well-structured with sections (Args, Returns, Raises, Note) and front-loaded purpose. While slightly lengthy, every paragraph adds value without redundancy.

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 an output schema exists, description adequately covers return format and algorithm internals. However, it could detail the expected structure of the optimization_problem object (e.g., required keys).

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 coverage is 0%, but the description adds meaning to both parameters: 'optimization_problem: Problem definition (objective, constraints, variables)' and 'ga_parameters: Optional GA parameters (population_size, generations, etc.)'. This compensates for the missing schema descriptions.

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 explicitly states 'Optimize spacecraft trajectory using genetic algorithm', which is a specific verb-resource pair and clearly distinguishes from siblings like particle_swarm_optimization.

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 lacks guidance on when to use GA vs other optimization tools (e.g., particle swarm). No context on problem types suited for GA or when not to use it.

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

geodetic_to_ecefA

Convert geodetic coordinates (lat/lon/alt) to Earth-centered Earth-fixed (ECEF) coordinates.

Args: latitude_deg: Latitude in degrees (-90 to 90) longitude_deg: Longitude in degrees (-180 to 180) altitude_m: Altitude above WGS84 ellipsoid in meters

Returns: JSON string with ECEF X, Y, Z coordinates in meters.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: The geodetic-to-ECEF conversion uses the WGS84 ellipsoid parameters: a = 6378137.0 m (semi-major axis, equatorial radius) f = 1/298.257223563 (flattening) e^2 = 2f - f^2 (first eccentricity squared)

The conversion equations are:
    N = a / sqrt(1 - e^2 * sin^2(lat))   (radius of curvature in prime vertical)
    X = (N + h) * cos(lat) * cos(lon)
    Y = (N + h) * cos(lat) * sin(lon)
    Z = (N * (1 - e^2) + h) * sin(lat)
where lat, lon are geodetic latitude/longitude and h is altitude above ellipsoid.
ParametersJSON Schema
NameRequiredDescriptionDefault
latitude_degYes
longitude_degYes
altitude_mNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/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. It details the WGS84 ellipsoid parameters, conversion equations, and notes that exceptions are not raised but errors returned as strings. This is transparent about the mathematical model and error handling, though it omits any side effects or authorization needs (likely none).

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 sections for Args, Returns, Raises, and Note. However, it includes detailed formulas and ellipsoid parameters which, while informative, could be more concise. The first sentence efficiently captures the purpose, and the structure aids readability.

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 tool's moderate complexity (3 parameters, no nested objects) and the presence of an output schema (indicated), the description covers parameters, return format, error handling, and the underlying model completely. No significant gaps remain.

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?

The input schema has 0% description coverage, so the description is essential. It adds meaningful context beyond the schema: specifies valid ranges for latitude and longitude, explains altitude above WGS84 ellipsoid, and notes the default of 0 for altitude. This sufficiently compensates for 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 'Convert geodetic coordinates (lat/lon/alt) to Earth-centered Earth-fixed (ECEF) coordinates.' This specifies the exact operation and resource, and the sibling list includes 'ecef_to_geodetic' which implicitly distinguishes the inverse direction.

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 does not explicitly state when to use this tool versus alternatives. It implies usage for geodetic-to-ECEF conversion, but does not mention the inverse tool or any conditions for choosing among sibling tools.

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

get_aircraft_performanceA

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.

Raises: No exceptions are raised directly; errors are returned as formatted strings. Internally catches OpenAPError for unsupported aircraft types.

ParametersJSON Schema
NameRequiredDescriptionDefault
aircraft_typeYes
distance_kmYes
cruise_altitude_ftNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations provided, so the description must carry the full burden. It mentions external dependency OpenAP, internal error handling, and that errors are returned as strings. However, it does not state whether the tool is read-only or other behavioral traits.

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 fairly concise with clear sections for Args, Returns, Raises. It could be slightly more terse, but overall well-structured.

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 presence of an output schema, the description adequately covers inputs, return format, and error handling. It does not detail the output fields, but that is handled by the output schema.

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 adds essential meaning: aircraft_type is an ICAO code, distance_km in kilometers, cruise_altitude_ft in feet. It does not mention the default value for cruise_altitude_ft.

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 gets performance estimates for an aircraft type, with a specific verb and resource. It also notes the requirement for OpenAP, distinguishing it from siblings like get_airfoil_database.

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?

No explicit guidance on when to use this tool versus alternatives. The mention of OpenAP requirement implies a prerequisite but does not help an agent decide between this and other performance tools.

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

get_airfoil_databaseA

Get available airfoil database with aerodynamic coefficients.

Returns: JSON string with airfoil database containing aerodynamic coefficients.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

The description discloses the return format (JSON string) and error handling (errors as formatted strings). Since no annotations are provided, these details are essential. It does not mention side effects, but for a read-only tool this is acceptable.

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 extremely concise with a clear structure: a purpose sentence followed by Returns and Raises sections. Every sentence adds value and no unnecessary words are present.

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?

For a tool with no parameters and an output schema, the description provides sufficient information: it states the output type, content, and error behavior. No gaps remain for the agent to use it correctly.

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?

The tool has zero parameters, so the schema is already clear. The description adds no additional parameter meaning, but none is needed. Baseline score of 4 is appropriate.

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 gets an airfoil database with aerodynamic coefficients. The verb 'Get' and specific resource 'airfoil database' make the purpose unambiguous, distinguishing it from sibling tools like get_propeller_database or get_aircraft_performance.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any preconditions, limitations, or alternatives, leaving the agent to infer usage context.

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

get_atmosphere_profileB

Get atmospheric properties (pressure, temperature, density) at specified altitudes using ISA model.

Args: altitudes_m: List of altitudes in meters model_type: Atmospheric model type ('ISA' for standard, 'enhanced' for extended)

Returns: Formatted string with atmospheric profile data including pressure, temperature, density, and speed of sound at each altitude.

Raises: No exceptions are raised directly; errors are returned as formatted strings. ImportError is caught when the ambiance package is not installed.

ParametersJSON Schema
NameRequiredDescriptionDefault
altitudes_mYes
model_typeNoISA

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

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

Annotations are absent, so the description carries the full burden. It discloses that errors are returned as formatted strings and that an ImportError is caught. However, it does not mention possible limitations such as altitude range bounds or computational performance.

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 uses a clear docstring format with Args, Returns, and Raises sections. It is concise without extraneous information, though it could be slightly shorter without losing clarity.

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 two parameters and no annotations, the description adequately covers input meanings, return format (formatted string), and error handling. It lacks explicit altitude range constraints but remains sufficiently complete for basic usage.

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?

The description explains 'altitudes_m' as a list of altitudes in meters and 'model_type' as ISA or enhanced, adding meaning beyond the schema's type and enum definitions. Despite 0% schema description coverage, the description compensates well.

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?

Clearly states the tool gets atmospheric properties (pressure, temperature, density) at specified altitudes using the ISA model. The verb 'Get' and specific resources are unambiguous. However, it does not explicitly differentiate from the sibling tool 'density_altitude_calculator', which may 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?

No information is provided about when to use this tool over alternatives like density_altitude_calculator or other atmospheric tools. There is no mention of prerequisites or contextual cues for selection.

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

get_propeller_databaseA

Get available propeller database with geometric and performance data.

Returns: JSON string with propeller database containing geometry and performance data.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

The description states it returns a JSON string and that errors are returned as formatted strings, not exceptions. With no annotations, it partially covers behavioral traits but lacks details on data freshness, availability, or performance impact.

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?

Description is extremely concise: two sentences plus a note about exceptions. No redundant information; every sentence adds value.

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 simple parameterless tool with an output schema, the description covers purpose, return type, and error handling. It is reasonably complete given the low complexity.

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?

The tool has zero parameters (input schema empty). Schema description coverage is 100% (by default). The description correctly states the resource and return format, which is sufficient for a parameterless tool.

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 uses the verb 'get' and specifies the resource 'propeller database' with geometric and performance data. It clearly distinguishes from sibling tools like propeller_bemt_analysis (which performs analysis) and get_airfoil_database (a different database).

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?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving the database, but does not mention when to avoid or compare to siblings like propeller_bemt_analysis.

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

get_system_statusA

Get system status and capabilities.

Returns: JSON string with system status information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses the return type as a JSON string with system status. Though it doesn't explicitly state read-only, the verb 'get' implies non-destructive behavior.

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?

Single sentence, no fluff, directly explains what the tool does. Every word earns its place.

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 output schema exists, the return format note is sufficient. The description is complete for a simple, parameterless tool.

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?

No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4. Description adds no extra param info, but none is needed.

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 'Get system status and capabilities', which is a specific verb+resource. It distinguishes itself from sibling tools that are domain-specific by being a general system utility.

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?

No guidance on when to use this tool vs alternatives. For a generic tool among many specialized ones, explicit context would help the agent decide.

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

hohmann_transferA

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 including delta-V for each burn, transfer orbit semi-major axis, and time of flight.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: The Hohmann transfer is the minimum-energy two-impulse transfer between coplanar circular orbits. Using the vis-viva equation v^2 = mu*(2/r - 1/a): a_transfer = (r1 + r2) / 2 delta_V1 = sqrt(mu/r1) * (sqrt(2r2/(r1+r2)) - 1) (departure burn) delta_V2 = sqrt(mu/r2) * (1 - sqrt(2r1/(r1+r2))) (arrival burn)

ParametersJSON Schema
NameRequiredDescriptionDefault
r1_mYes
r2_mYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the calculation itself. It lacks information on side effects, resource usage, or error handling behavior beyond a brief note on error returns.

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 follows a clear docstring format with Args, Returns, Raises, and a Note. It is well-structured but includes detailed formulas, which while informative, add length. It could be slightly more concise without losing value.

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?

The description mentions that the tool returns a JSON string with specific parameters (delta-V, semi-major axis, time of flight) and notes error handling. Given the presence of an output schema and the simplicity of the tool (two parameters), the description is reasonably complete.

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?

The description fully explains the two parameters (r1_m and r2_m) as initial and final orbit radii in meters, and provides the underlying formulas. This adds significant meaning beyond the schema, which has 0% description coverage.

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 'Calculate Hohmann transfer orbit parameters between two circular orbits,' specifying the verb, resource, and scope. It distinguishes the tool from siblings like 'orbital_rendezvous_planning' by focusing on the specific Hohmann transfer method.

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

Usage Guidelines4/5

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

The description explains when to use the tool via the note on Hohmann transfer being the minimum-energy two-impulse transfer between coplanar circular orbits. However, it does not explicitly state when not to use it or mention alternatives, slightly limiting guidance.

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

kalman_filter_state_estimationA

Extended Kalman Filter for aircraft/spacecraft state estimation.

Implements a Kalman filter for sensor fusion and state estimation from noisy measurements.

Args: initial_state: Initial state vector estimate initial_covariance: Initial state covariance matrix (P0) process_noise: Process noise covariance matrix (Q) measurement_noise: Measurement noise covariance matrix (R) measurements: Time-series of measurements, each with: - time: Measurement timestamp - z: Measurement vector - H: Optional measurement matrix (uses identity if not provided) dynamics_model: Dynamics model type: - "constant_velocity": 2D position + velocity - "constant_acceleration": 2D position + velocity + acceleration - "orbital": Simplified orbital dynamics dt: Time step for prediction (used if not in measurements)

Returns: Formatted string with filtered state estimates, covariance diagonals, and innovation statistics.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
initial_stateYes
initial_covarianceYes
process_noiseYes
measurement_noiseYes
measurementsYes
dynamics_modelNoconstant_velocity
dtNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It states that errors are returned as formatted strings and lists key parameters, but lacks details on computational behavior, side effects, or limitations (e.g., convergence, state dimension compatibility).

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

Conciseness3/5

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

The description contains redundant phrases ('Extended Kalman Filter' and 'Kalman filter') and is lengthy due to the Args block. While structured and front-loaded with purpose, it could be more succinct without losing clarity.

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?

The tool is complex with 7 parameters and no output schema, but the description covers inputs well and specifies the return type as a formatted string. However, it lacks examples, preconditions (e.g., state vector size consistency), and assumptions, which narrows completeness for a state estimation 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?

The input schema has no property descriptions (title only), but the description's Args section provides detailed explanations for all 7 parameters, including the mechanics of the 'measurements' array and enum options for 'dynamics_model'. This fully compensates for the schema's lack.

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 'Extended Kalman Filter for aircraft/spacecraft state estimation' and elaborates on sensor fusion and state estimation from noisy measurements. This distinguishes it from sibling tools like 'calculate_distance' or 'estimate_rocket_sizing'.

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 mentions 'sensor fusion' and 'state estimation' as typical use cases but does not explicitly differentiate from alternatives or provide when-not-to-use guidance. The dynamics_model options hint at different contexts but no comparative advice.

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

lambert_problem_solverA

Solve Lambert's orbital boundary value problem.

Given two position vectors and time-of-flight, determine the orbit connecting them. This is foundational for interplanetary mission design and rendezvous trajectory planning.

Args: r1_m: Initial position vector [x, y, z] in meters r2_m: Final position vector [x, y, z] in meters tof_s: Time of flight in seconds direction: Transfer direction - "prograde" or "retrograde" num_revolutions: Number of complete revolutions (default 0 for short path) central_body: Central body name for gravitational parameter

Returns: JSON string with transfer orbit velocities, orbital elements, transfer angle, and timing information.

Raises: No exceptions are raised directly; errors are returned as JSON strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
r1_mYes
r2_mYes
tof_sYes
directionNoprograde
num_revolutionsNo
central_bodyNoearth

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
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. It discloses that errors are returned as JSON strings and no exceptions are raised directly, but it does not mention any behavioral traits like computational cost, required authority, or side effects. The description adds minimal transparency beyond stating what the tool computes.

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 concise and well-structured with a clear introductory sentence, an Args section, and brief Returns and Raises sections. It efficiently conveys the necessary information without unnecessary verbosity.

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?

The description covers parameters and return values adequately given the presence of an output schema. However, it omits important contextual details such as the coordinate frame for position vectors (e.g., ECI) or a list of valid central_body names, which could lead to ambiguity for users unfamiliar with astrodynamics conventions.

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?

The schema description coverage is 0%, so the description must compensate. The Args section provides clear, informative descriptions for each parameter: units for vectors and time, explanation of direction and revolutions, and a note on central_body. This adds significant meaning beyond the schema's type and default information.

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 identifies the tool as solving Lambert's orbital boundary value problem, specifying the inputs (two position vectors and time-of-flight) and the output (orbit connecting them). It also mentions its application in interplanetary mission design and rendezvous planning, which distinguishes it from sibling tools like hohmann_transfer or orbital_rendezvous_planning.

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 does not provide guidance on when to use this tool versus alternatives such as hohmann_transfer or porkchop_plot_analysis. It states the general purpose but lacks explicit context for when to choose this tool, nor does it mention situations where it should not be used.

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

landing_performanceA

Calculate landing distance for given conditions.

Args: weight_kg: Landing weight in kg pressure_altitude_ft: Airport pressure altitude in feet temperature_c: Outside air temperature in Celsius wind_kts: Headwind (+) or tailwind (-) in knots runway_slope_pct: Runway slope in percent (+ uphill) runway_condition: "dry", "wet", or "contaminated" cl_max_landing: Maximum lift coefficient in landing config wing_area_m2: Wing reference area in m² vref_factor: Approach speed factor (typically 1.3) approach_angle_deg: Approach angle in degrees

Returns: Formatted string with landing performance calculations including V-speeds, air distance from 50 ft, ground roll, and factored distances.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
weight_kgYes
pressure_altitude_ftYes
temperature_cYes
wind_ktsNo
runway_slope_pctNo
runway_conditionNodry
cl_max_landingNo
wing_area_m2No
vref_factorNo
approach_angle_degNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It mentions that errors are returned as formatted strings, which is helpful, but it does not disclose other behaviors such as performance characteristics or prerequisites.

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 a well-structured docstring with clear sections for Args, Returns, and Raises. It is concise yet covers all necessary details without superfluous content.

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 tool's complexity (10 parameters) and lack of parameter descriptions in the schema, the description fully explains inputs and return format, making it complete for use.

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?

The description provides a detailed explanation for each parameter, including units and roles (e.g., 'weight_kg: Landing weight in kg'). This adds significant value beyond the schema, which only has titles and types.

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 calculates landing distance for given conditions. The tool name supports this purpose, and among siblings like 'takeoff_performance' and 'stall_speed_calculator', it is distinct.

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 lacks explicit guidance on when to use this tool versus alternatives. It only implies usage through the calculation purpose, but does not provide context for exclusion or mention sibling tools.

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

list_tool_categoriesA

List all available tool categories with tool counts.

Returns: JSON string with an array of categories (name and tool_count) and the total number of registered tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

The description discloses the return format (JSON string with categories and total count) and implies it is a read-only operation ('list'). Since no annotations are provided, the description carries the full burden, and it clearly communicates the output structure. However, it does not explicitly state that the tool is non-destructive or free of side effects, which would warrant a 5.

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 two sentences, no extraneous information. It front-loads the core purpose and then specifies the return value. Every sentence is necessary and efficient.

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?

For a simple listing tool with no parameters and an output schema (even if not shown), the description fully explains the input (none) and output (categories with counts). It covers the essential information an agent needs to invoke and interpret the result.

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?

The tool has zero parameters, so the schema is empty and coverage is trivial. Per guidelines, zero-parameter tools receive a baseline of 4. The description does not need to add parameter details.

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 lists tool categories with counts. The verb 'list' and resource 'tool categories' are explicit. However, it does not differentiate from siblings like 'search_aerospace_tools', which could also return category-related info, but the unique focus on categories and counts makes it distinct enough. A 5 would require explicit contrast.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., 'select_aerospace_tool'). The description only explains what it does, leaving the agent to infer usage context without exclusions or recommendations.

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

lqr_controller_designA

Design Linear Quadratic Regulator (LQR) optimal controller.

Computes optimal state-feedback gain K that minimizes the cost function: J = integral(x'Qx + u'Ru) dt

Args: A_matrix: State matrix (n x n) - system dynamics B_matrix: Input matrix (n x m) - control influence Q_matrix: State weighting matrix (n x n) - penalizes state deviation R_matrix: Input weighting matrix (m x m) - penalizes control effort state_names: Optional names for states (for display) input_names: Optional names for control inputs (for display)

Returns: Formatted string with optimal gain matrix K, closed-loop eigenvalues, stability analysis, and controllability assessment.

Raises: No exceptions are raised directly; errors are returned as formatted strings or JSON error objects (e.g., when system is not controllable).

ParametersJSON Schema
NameRequiredDescriptionDefault
A_matrixYes
B_matrixYes
Q_matrixYes
R_matrixYes
state_namesNo
input_namesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

Discloses return values (gain matrix, eigenvalues, stability, controllability) and error handling (returns formatted strings or JSON errors). No annotations, so description bears full burden; it covers key behaviors without missing critical info.

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?

Well-structured with intro, cost function, Args, Returns, Raises sections. Slightly verbose but all sentences earn their place. Could be more concise.

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 LQR complexity and no annotations, the description covers purpose, parameters, return, errors, and even controllability assessment. Output schema exists but description already explains return well. Complete for agent selection.

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?

Schema description coverage is 0%, but the description provides thorough explanations: matrix dimensions, roles (system dynamics, control influence, weighting), and optional use of state/input names. Adds meaning beyond schema types.

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 'Design Linear Quadratic Regulator (LQR) optimal controller' with a specific verb and resource. It explains the cost function and output, distinguishing it from sibling aerospace tools.

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?

No guidance on when to use this tool versus alternatives or prerequisites like system controllability. The description assumes user knowledge without context.

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

monte_carlo_uncertainty_analysisA

Perform Monte Carlo uncertainty analysis on spacecraft trajectory.

Args: nominal_trajectory: Nominal trajectory parameters uncertainty_parameters: Parameters with uncertainty distributions n_samples: Number of Monte Carlo samples analysis_options: Optional analysis settings

Returns: JSON string with uncertainty analysis results including statistical summaries (mean, std, percentiles) of trajectory metrics.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: Monte Carlo analysis samples uncertain parameters from their specified distributions (e.g., Gaussian, uniform) and runs n_samples trajectory simulations. Statistical analysis of the results provides: - Mean and standard deviation of key performance metrics. - Confidence intervals (e.g., 95th percentile bounds). - Dispersion ellipses for correlated output parameters. Latin Hypercube Sampling (LHS) may be used for efficient coverage of the parameter space with fewer samples than pure random sampling.

ParametersJSON Schema
NameRequiredDescriptionDefault
nominal_trajectoryYes
uncertainty_parametersYes
n_samplesNo
analysis_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

Despite no annotations, the description discloses key behaviors: sampling from specified distributions, running n_samples simulations, statistical analysis, and error handling ('errors are returned as formatted strings'). It also mentions Latin Hypercube Sampling for efficiency.

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 a clear first sentence, then a parameter list, return description, and additional notes. It is concise for a complex tool, though the parameter list uses a docstring style that could be more compact.

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 complexity and lack of annotations, the description covers purpose, parameters, return value (including statistical summaries), and sampling method. Output schema exists but its content is not shown; the description adequately summarizes expected output.

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 provides brief but clear parameter descriptions (e.g., 'uncertainty_parameters: Parameters with uncertainty distributions'), adding meaning beyond the schema's empty property definitions.

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: 'Perform Monte Carlo uncertainty analysis on spacecraft trajectory.' This is a specific verb ('perform') and resource ('Monte Carlo uncertainty analysis on spacecraft trajectory'), distinguishing it from siblings like 'trajectory_sensitivity_analysis'.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., sensitivity analysis, Kalman filtering). The description implies use for uncertainty propagation but does not provide when-not-to-use or list of alternative tools.

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

optimize_launch_angleA

Optimize rocket launch angle for maximum altitude or range.

Args: rocket_geometry: Rocket geometry parameters target_range_m: Optional target range in meters optimize_for: Optimization objective ('altitude' or 'range') angle_bounds_deg: Launch angle bounds in degrees

Returns: JSON string with optimization results including optimal angle and resulting performance metrics.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
rocket_geometryYes
target_range_mNo
optimize_forNoaltitude
angle_bounds_degNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that errors are returned as strings, not raised, and that output is a JSON string with results. However, it does not disclose computational cost, side effects, or whether the optimization is deterministic or stochastic.

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 well-structured: a one-line summary, then bullet-pointed args, returns, and raises. Every sentence is informative with no redundancy.

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?

The description covers basic purpose and parameters, and the output schema exists to inform return structure. However, it lacks details on optimization algorithm, assumptions, and when to prefer this over similar tools. It is minimally complete but leaves gaps for a complex optimization tool.

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 coverage is 0%, so the description adds value by explaining each parameter briefly (e.g., 'Rocket geometry parameters', 'Optional target range in meters'). However, it does not detail the expected structure of 'rocket_geometry' (which is a flexible object) or specify units for angle_bounds_deg.

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: 'Optimize rocket launch angle for maximum altitude or range.' This distinguishes it from siblings like 'optimize_thrust_profile' and 'rocket_3dof_trajectory' which handle different aspects of rocket optimization and simulation.

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 explicit guidance on when to use this tool versus alternatives like 'trajectory_sensitivity_analysis' or 'particle_swarm_optimization'. It does not mention prerequisites or situations where the tool is inappropriate.

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

optimize_thrust_profileC

Optimize rocket thrust profile for better performance using trajectory optimization.

Args: rocket_geometry: Rocket geometry parameters burn_time_s: Burn time in seconds total_impulse_target: Target total impulse in N⋅s n_segments: Number of thrust segments objective: Optimization objective

Returns: JSON string with optimized thrust profile including segment-wise thrust levels and resulting trajectory performance.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
rocket_geometryYes
burn_time_sYes
total_impulse_targetYes
n_segmentsNo
objectiveNomax_altitude

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions that errors are returned as strings (no exceptions) and returns a JSON string, but lacks details on side effects, required data formats, or performance implications, offering minimal 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 concise, with a clear structure (purpose, args, returns, raises), and front-loads the action. Every sentence adds value, though the args list could be slightly more compact.

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 complexity (5 params, nested objects, output schema), the description covers basic functionality but omits details about optimization method, constraints, or typical use cases. It is adequate but not thorough.

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 adds meaning to all 5 parameters with brief clarifications (e.g., 'Burn time in seconds'). However, 'rocket_geometry' is vaguely described as 'Rocket geometry parameters' without specifying expected fields, leaving ambiguity.

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 optimizes rocket thrust profiles using trajectory optimization, specifying the resource and action. It does not explicitly differentiate from sibling tools like 'optimize_launch_angle' or 'genetic_algorithm_optimization', but the name and specificity make the purpose clear.

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?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites, limitations, or contextual hints. This leaves the agent without direction for selection among similar optimization tools.

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

orbital_rendezvous_planningB

Plan orbital rendezvous maneuvers between two spacecraft.

Args: chaser_elements: Chaser spacecraft orbital elements target_elements: Target spacecraft orbital elements rendezvous_options: Optional rendezvous planning parameters

Returns: JSON string with rendezvous plan including maneuver sequence and delta-V.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
chaser_elementsYes
target_elementsYes
rendezvous_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It mentions no exceptions are raised (errors as strings) and returns a JSON plan, but does not disclose constraints, input validation, or behavior for edge cases.

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?

Description is concise with a clear first sentence. The docstring format adds structure, though some reformatting could reduce verbosity. Overall, every part earns its place.

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

Completeness2/5

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

Given the complexity (three object parameters, nested objects) and lack of schema descriptions, the description is insufficient. It does not explain what constitutes valid orbital elements or rendezvous options, leaving the agent without enough detail to prepare inputs correctly.

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%, but description adds that chaser/target_elements are 'orbital elements' and rendezvous_options is 'optional rendezvous planning parameters', providing some context beyond the bare schema. However, it does not specify the required structure or available options.

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 plans orbital rendezvous maneuvers between two spacecraft, using a specific verb and resource. This distinguishes it from sibling tools like hohmann_transfer and lambert_problem_solver.

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?

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for selection among many aerospace planning tools.

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

particle_swarm_optimizationA

Optimize spacecraft trajectory using particle swarm optimization.

Args: optimization_problem: Problem definition (objective, constraints, variables) pso_parameters: Optional PSO parameters (n_particles, iterations, etc.)

Returns: JSON string with optimization results including best position found and convergence metrics.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: PSO updates each particle's velocity and position at every iteration: v_i(t+1) = wv_i(t) + c1r1*(p_best_i - x_i) + c2r2(g_best - x_i) x_i(t+1) = x_i(t) + v_i(t+1) where w is the inertia weight (balances exploration vs exploitation), c1/c2 are cognitive/social acceleration coefficients, r1/r2 are random numbers in [0,1], p_best_i is the particle's personal best, and g_best is the global best found by any particle in the swarm.

ParametersJSON Schema
NameRequiredDescriptionDefault
optimization_problemYes
pso_parametersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

Given no annotations, the description effectively discloses key behaviors: the PSO update formula, error handling (errors returned as formatted strings), and algorithmic details. However, it does not explicitly state whether the tool has side effects (it is likely read-only), nor does it mention prerequisites or rate limits, which would elevate 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 front-loaded with the purpose, then systematically covers args, returns, errors, and a note. The inclusion of the full update formula is dense but valuable. It is appropriately sized for a complex optimization tool, though some redundancy exists (e.g., repeating parameters in args and later).

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 presence of an output schema and the input schema's genericity, the description provides sufficient context for a scientific tool: it explains the algorithm, return format, and error handling. Minor gaps include no elaboration on variable types or constraints in the problem definition, but overall it meets the complexity level.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: optimization_problem as 'Problem definition (objective, constraints, variables)' and pso_parameters as 'Optional PSO parameters (n_particles, iterations, etc.).' This adds meaningful structural hints beyond the raw schema, though it does not enumerate all subfields.

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: 'Optimize spacecraft trajectory using particle swarm optimization.' It specifies the verb (optimize), resource (spacecraft trajectory), and method (PSO), distinguishing it from sibling optimization tools like genetic algorithm or Monte Carlo.

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 like genetic_algorithm_optimization or monte_carlo_uncertainty_analysis. It neither suggests appropriate scenarios nor warns about limitations, leaving the agent without decision-making context.

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

plan_flightA

Plan a flight route between two airports with performance estimates.

Args: departure: Dict with departure info (city, country, iata) arrival: Dict with arrival info (city, country, iata) aircraft: Optional aircraft config (ac_type, cruise_alt_ft, route_step_km) route_options: Optional route options

Returns: JSON string with flight plan details including departure/arrival airports, route waypoints, distances, and optional performance estimates.

Raises: No exceptions are raised directly; errors are returned as formatted strings. Internally catches AirportResolutionError and OpenAPError.

ParametersJSON Schema
NameRequiredDescriptionDefault
departureYes
arrivalYes
aircraftNo
route_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It explains that errors are caught internally and returned as strings, and it outlines the return structure. This provides good insight into the tool's behavior.

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 well-structured with 'Args', 'Returns', and 'Raises' sections. Every sentence adds value, and there is no redundancy. It is appropriately sized for the tool's complexity.

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 output schema exists (implied by the detailed return description), the description adequately covers return values. It also mentions error handling. However, it lacks information about prerequisites or required permissions, but these are not critical for this tool.

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?

The schema has 0% description coverage, but the description adds meaning by specifying that 'departure' and 'arrival' are dicts with 'city', 'country', 'iata', and that 'aircraft' includes 'ac_type', 'cruise_alt_ft', 'route_step_km'. This significantly compensates for the schema's lack of detail.

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 states 'Plan a flight route between two airports with performance estimates', which is a specific verb+resource combination. This clearly distinguishes it from sibling tools like 'calculate_distance' or 'get_aircraft_performance'.

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 flight route planning but does not explicitly state when to use this tool versus alternatives like 'calculate_distance' or 'get_aircraft_performance'. There is no when-not-to-use guidance.

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

porkchop_plot_analysisA

Generate porkchop plot for interplanetary transfer opportunities.

Args: departure_body: Departure celestial body name arrival_body: Arrival celestial body name departure_date_range: Range of departure dates (ISO format) arrival_date_range: Range of arrival dates (ISO format) analysis_options: Optional analysis settings

Returns: JSON string with porkchop plot data (departure date vs arrival date grid with delta-V contours for identifying optimal launch windows).

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
departure_bodyYes
arrival_bodyYes
departure_date_rangeYes
arrival_date_rangeYes
analysis_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions error handling (errors returned as strings) and return format (JSON string), but lacks details on computational complexity, assumptions (e.g., two-body problem), or required ephemeris data.

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 concise and well-structured, using a clear docstring format with summary, args, returns, and raises. Every sentence serves a purpose, and the key information is front-loaded in the first sentence.

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 complexity (5 parameters, date ranges, optional settings) and an existing output schema (not shown), the description covers the essentials: input descriptions, return type, and error handling. It could specify allowed celestial body names or date format constraints more precisely, but is largely complete.

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?

Despite 0% schema description coverage, the description provides meaningful docstring-style explanations for each parameter (e.g., 'Departure celestial body name', 'Range of departure dates (ISO format)'). This adds significant value beyond the schema's bare types and titles. However, 'analysis_options' is described vaguely as 'Optional analysis settings'.

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 starts with a specific verb and resource: 'Generate porkchop plot for interplanetary transfer opportunities.' It clearly distinguishes from sibling tools like hohmann_transfer or lambert_problem_solver by focusing on delta-V contour plots for launch window identification.

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 analyzing interplanetary transfer opportunities via a date-grid approach, but does not explicitly state when to use this tool versus alternatives (e.g., hohmann_transfer for impulsive maneuvers). No when-not or alternative suggestions are provided.

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

propagate_orbit_j2A

Propagate orbit with J2 perturbations using numerical integration.

Args: initial_state: Initial orbital state (elements or state vector) propagation_time_s: Propagation time in seconds time_step_s: Integration time step in seconds

Returns: JSON string with propagated state vectors at each time step.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
initial_stateYes
propagation_time_sYes
time_step_sNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description is responsible for all behavioral disclosure. It mentions numerical integration and J2 perturbations, and notes that errors are returned as strings rather than exceptions. However, it omits any discussion of side effects, performance, or required permissions, leaving gaps.

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 concise and well-structured with Args and Returns sections. Every sentence contributes useful information, and the front-loading of the purpose sentence makes it immediately clear what the tool does.

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 that an output schema exists, the description need not detail return values. It covers the three parameters adequately and mentions error handling. For a moderately complex orbital propagation tool, the description provides sufficient context for an AI agent to use it correctly, though more detail on initial state format would improve completeness.

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 coverage is 0%, so the description must compensate. It lists the three parameters with brief explanations (e.g., 'Initial orbital state (elements or state vector)') which adds meaning beyond the parameter names. However, it does not specify the expected format of the initial_state object or any constraints on the time step.

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: propagate orbit with J2 perturbations via numerical integration. The verb 'propagate' and resource 'orbit' are specific, and the mention of 'J2 perturbations' distinguishes it from other orbital tools on the server.

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 lists arguments but does not specify scenarios, prerequisites, or cases where other tools (e.g., hohmann_transfer) would be more appropriate.

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

propeller_bemt_analysisA

Analyze propeller performance using Blade Element Momentum Theory.

Args: propeller_geometry: Propeller geometry (diameter_m, pitch_m, num_blades, etc.) operating_conditions: Operating conditions (rpm_list, velocity_ms, altitude_m) analysis_options: Optional analysis settings

Returns: Formatted string with propeller performance analysis including thrust, torque, power, efficiency, and advance ratio at each RPM.

Raises: No exceptions are raised directly; errors are returned as formatted strings. ImportError is caught when propulsion packages are not installed.

Note: BEMT iteratively solves for the inflow angle (phi) at each blade element by balancing: 1. Blade Element Theory: Local lift and drag from 2D airfoil data at the effective angle of attack (alpha = phi - pitch_angle). 2. Momentum Theory: Axial and tangential momentum changes through an annular ring of the rotor disk. Convergence is achieved when the induced velocity factors (a, a') satisfy both theories simultaneously. The advance ratio J = V / (n*D) characterizes the operating condition.

ParametersJSON Schema
NameRequiredDescriptionDefault
propeller_geometryYes
operating_conditionsYes
analysis_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description fully discloses behavioral traits: it explains the iterative BEMT convergence process, describes the theoretical foundation, mentions that errors are returned as formatted strings, and notes that ImportError is caught. This goes beyond minimal disclosure.

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

Conciseness3/5

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

The description is lengthy, with a detailed Note section that is more theoretical than practical for tool usage. While structured with Args/Returns/Raises sections, it could be trimmed without losing essential guidance.

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 params, no annotations, output schema exists), the description covers return format, error handling, and some parameter hints. However, it lacks full specification of expected object keys and does not reference the output schema. It is adequate but not complete.

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 coverage is 0%, so the description must compensate. It provides brief hints for each parameter (e.g., 'propeller_geometry: Propeller geometry (diameter_m, pitch_m, num_blades, etc.)'), but does not fully specify the expected structure or constraints. The examples help but are incomplete.

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: 'Analyze propeller performance using Blade Element Momentum Theory.' This is a specific verb+resource combination and distinguishes it from sibling tools like get_propeller_database, which retrieves data rather than performing analysis.

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 explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or what other tools might be more appropriate (e.g., for simpler performance estimates). There are no context signals about usage.

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

rocket_3dof_trajectoryA

Calculate 3DOF rocket trajectory using numerical integration.

Args: rocket_geometry: Rocket geometry parameters launch_conditions: Launch conditions (launch_angle_deg, launch_site, etc.) simulation_options: Optional simulation settings

Returns: Formatted string with trajectory analysis results including max altitude, max velocity, Mach number, apogee time, burnout time, max-Q, total impulse, and specific impulse.

Raises: No exceptions are raised directly; errors are returned as formatted strings. ImportError is caught when rocketry packages are not installed.

Note: The 3DOF equations of motion integrate: dv/dt = (T - D) / m - g * sin(gamma) (along velocity) dgamma/dt = -(g / v) * cos(gamma) (flight path angle) dx/dt = v * cos(gamma) (downrange) dh/dt = v * sin(gamma) (altitude) where T is thrust, D = 0.5 * rho(h) * v^2 * Cd * A_ref is aerodynamic drag with altitude-dependent density, m is instantaneous mass (decreasing during burn), and gamma is the flight path angle. Integration uses a 4th-order Runge-Kutta (RK4) scheme for numerical stability.

ParametersJSON Schema
NameRequiredDescriptionDefault
rocket_geometryYes
launch_conditionsYes
simulation_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it uses RK4 integration, explains the equations of motion, handles errors by returning formatted strings (no exceptions), and depends on rocketry packages. This exceeds typical expectations.

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-organized (Args, Returns, Raises, Note) and front-loaded with purpose. However, the equations section is verbose; some repetition could be trimmed. Still, it is efficiently structured for clarity.

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?

The description explains the output (formatted string with key results) and the physics, but lacks detailed input guidance for the two required complex objects. Given the tool's complexity and minimal schema, more input context is needed for complete usage.

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 coverage is 0%, so the description must compensate. It only provides vague labels like 'Rocket geometry parameters' and one example ('launch_angle_deg, launch_site, etc.'). It does not list expected keys, types, or constraints, leaving significant ambiguity.

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 calculates a 3DOF rocket trajectory using numerical integration. It specifies the resource (rocket trajectory) and the method (numerical integration), distinguishing it from siblings like trajectory_sensitivity_analysis or optimize_launch_angle.

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 explicit guidance on when to use this tool versus alternative trajectory tools. It does not mention prerequisites, when not to use it, or compare to other tools like trajectory_sensitivity_analysis.

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

search_aerospace_toolsA

Search for aerospace-mcp tools by name, description, or functionality.

This tool enables dynamic tool discovery, allowing Claude to find relevant tools from the 34+ available aerospace tools without loading all definitions upfront. Returns tool references matching the search query.

Args: query: Search query - regex pattern (for regex mode) or natural language (for text mode) search_type: Search mode - 'regex' for pattern matching, 'text' for natural language, 'auto' to detect based on query characteristics max_results: Maximum number of tools to return (default 5, max 10) category: Optional category filter (core, atmosphere, frames, aerodynamics, propellers, rockets, orbits, optimization, agents)

Returns: JSON string with tool references matching the query, including both machine-readable tool_reference blocks and human-readable details.

Raises: No exceptions are raised directly; errors are returned in JSON format.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
search_typeNoauto
max_resultsNo
categoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: search modes (regex, text, auto), max_results limit, category filter, return format (JSON with tool references), and error handling (errors returned in JSON, no exceptions). This provides complete behavioral 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 well-structured with a clear purpose statement, followed by a usage benefit paragraph, then an Args section. Every sentence adds value, though it could be slightly more concise by merging the first two sentences. Overall, it is appropriately sized and front-loaded.

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 no annotations and the presence of an output schema (mentioned but not shown), the description covers all essential context: input parameters with details, return format, and error handling. It is complete for a search/discovery tool with 4 parameters and a clear result type.

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?

Schema description coverage is 0%, but the description explains each parameter in detail: query (regex pattern or natural language), search_type (modes with examples), max_results (default 5, max 10), category (optional filter with examples). This fully compensates for the schema's lack of descriptions.

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 searches for aerospace-mcp tools by name, description, or functionality. It uses a specific verb-resource pair ('search for aerospace-mcp tools') and explicitly differentiates from sibling tools by noting it enables dynamic tool discovery without loading all 34+ definitions upfront.

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

Usage Guidelines4/5

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

The description explains the tool allows finding relevant tools without loading all definitions, implying use when tool discovery is needed. However, it does not explicitly state when not to use it or list alternative tools like select_aerospace_tool, so it lacks exclusion guidance.

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

search_airportsA

Search for airports by IATA code or city name.

Args: query: IATA code (e.g., 'SJC') or city name (e.g., 'San Jose') country: Optional ISO country code to filter by (e.g., 'US', 'JP') query_type: Type of query - 'iata' for IATA codes, 'city' for city names, 'auto' to detect

Returns: Formatted string with airport information

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
countryNo
query_typeNoauto

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that errors are returned as formatted strings rather than exceptions, and explains query_type behavior. This is sufficient for a non-destructive lookup tool.

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 docstring format with Args/Returns/Raises is well-structured and clear, though slightly verbose. The purpose is front-loaded. Minor redundancy does not detract significantly.

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?

The tool is simple (3 params, no nested objects), and the description covers all aspects: functionality, parameter usage, error handling, and return format. No additional context is needed.

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?

Schema coverage is 0%, but the description provides full meaning for all parameters: query accepts IATA or city, country is optional ISO filter, query_type controls detection mode. This far exceeds schema info.

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 'Search for airports by IATA code or city name,' which is a specific verb+resource. Among numerous aerospace calculation siblings, this lookup tool is distinct and easily differentiated.

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

Usage Guidelines4/5

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

While no explicit when-to-use guidance is given, the tool's purpose is clear and siblings are unrelated. The description does explain optional filters and query types, aiding appropriate use.

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

select_aerospace_toolA

Help select the most appropriate aerospace-mcp tool for a given task.

Uses GPT-5-Medium to analyze the user's task and recommend the best tool(s) along with guidance on how to use them.

Args: user_task: Description of what the user wants to accomplish user_context: Additional context about the user's situation (optional)

Returns: Recommendation with tool name(s) and usage guidance, including primary tool, secondary tools, workflow steps, and considerations.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
user_taskYes
user_contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses use of GPT-5-Medium and that errors are returned as strings, but does not mention side effects, authentication, or model reliability.

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 concise, using a few sentences followed by clear args/returns/raises sections. Every part adds value without redundancy.

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 tool's meta-nature and presence of output schema (not shown), the description covers purpose, parameters, return structure, and error handling, providing a complete picture for usage.

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 coverage is 0%, but description compensates by describing both parameters (user_task and user_context) in detail, adding meaning beyond schema titles.

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 states the tool selects the most appropriate aerospace-mcp tool for a given task, using GPT-5-Medium. It clearly distinguishes from sibling calculation tools by being a meta-tool.

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

Usage Guidelines4/5

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

The description implies when to use (when uncertain about tool choice) and provides guidance via args/returns, but lacks explicit when-not-to-use or alternatives, though no direct alternative exists on this server.

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

stall_speed_calculatorA

Calculate stall speeds for different aircraft configurations.

Args: weight_kg: Aircraft weight in kg wing_area_m2: Wing reference area in m² cl_max_clean: Maximum lift coefficient in clean configuration cl_max_takeoff: Max CL with takeoff flaps (optional) cl_max_landing: Max CL with landing flaps (optional) altitude_ft: Pressure altitude in feet load_factor: Load factor (default 1.0 for level flight)

Returns: Formatted string with stall speed calculations for each configuration, plus reference speeds (VREF, V2_min) and altitude correction.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
weight_kgYes
wing_area_m2Yes
cl_max_cleanYes
cl_max_takeoffNo
cl_max_landingNo
altitude_ftNo
load_factorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/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. It explains the function, behavior (no exceptions, errors returned as strings), and output format. However, it does not disclose any side effects or resource usage, which are unlikely for a calculator.

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 structured as a docstring with sections for args and returns, making it readable. It is somewhat lengthy but each sentence adds value. The main purpose is front-loaded in the first sentence.

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 7 parameters and an output schema (not shown), the description covers parameter meanings, return format (formatted string with specific speeds), and error handling. It lacks edge cases or performance notes but is sufficient for a calculator 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?

Schema description coverage is 0%, but the description includes a docstring that explains each parameter's purpose and units, e.g., 'weight_kg: Aircraft weight in kg.' This adds substantial semantic meaning beyond the schema's type-only information.

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 starts with 'Calculate stall speeds for different aircraft configurations,' which clearly states the action and target resource. This differentiates it from sibling tools like landing_performance or takeoff_performance, which have different scopes.

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 stall speed calculations but does not explicitly state when to use this tool versus alternatives like takeoff_performance or landing_performance. There is no mention of use cases or exclusions, leaving it to the agent to infer context.

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

state_vector_to_elementsA

Convert state vector to classical orbital elements.

Args: state_vector: Dict with position_m and velocity_ms arrays

Returns: JSON string with classical orbital elements (a, e, i, RAAN, omega, nu).

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
state_vectorYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/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. It discloses that errors are returned as formatted strings and no exceptions are raised, which adds some transparency. However, it does not discuss side effects, authorized states, or any other behavioral traits beyond the return format.

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 concise, with the purpose front-loaded. The Args and Returns sections are clearly separated, but there is a minor redundancy in stating the return type both in the first line and the Returns section. Still, it is well-structured and avoids unnecessary words.

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 that the tool has an output schema (not shown) and handles a complex conversion, the description covers the basic input format and return structure. However, it omits details such as the units of the orbital elements (e.g., a in meters or km?) and what constitutes a valid state vector input (e.g., size of arrays). The error handling description is basic.

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?

The input schema describes 'state_vector' as an object with no explicit structure, but the description adds significant meaning: it specifies it expects a dict with 'position_m' and 'velocity_ms' arrays, including units. This compensates for the 0% schema description coverage and clarifies the required keys.

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 starts with a clear verb and resource: 'Convert state vector to classical orbital elements.' It clearly specifies the action and the output, and the sibling tool 'elements_to_state_vector' provides a direct contrast, making the purpose unambiguous.

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 in orbital mechanics contexts ('convert state vector to classical orbital elements') but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or special cases.

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

takeoff_performanceA

Calculate takeoff field length and V-speeds.

Uses simplified performance equations for educational purposes.

Args: weight_kg: Takeoff weight in kg pressure_altitude_ft: Airport pressure altitude in feet temperature_c: Outside air temperature in Celsius wind_kts: Headwind (+) or tailwind (-) in knots runway_slope_pct: Runway slope in percent (+ uphill) runway_condition: "dry", "wet", or "contaminated" thrust_to_weight: Thrust-to-weight ratio cl_max_takeoff: Maximum lift coefficient in takeoff config wing_area_m2: Wing reference area in m² cd0: Zero-lift drag coefficient oswald_e: Oswald efficiency factor aspect_ratio: Wing aspect ratio

Returns: Formatted string with takeoff performance calculations including V-speeds, ground roll, air distance to 35 ft, and factored distances.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
weight_kgYes
pressure_altitude_ftYes
temperature_cYes
wind_ktsNo
runway_slope_pctNo
runway_conditionNodry
thrust_to_weightNo
cl_max_takeoffNo
wing_area_m2No
cd0No
oswald_eNo
aspect_ratioNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

The description discloses that it uses simplified equations for education and that errors are returned as strings, but lacks details on limitations or side effects. No annotations exist to contradict or support.

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 a purpose line, Args list, Returns, and Raises. Each sentence is informative, though the Args list could be slightly more integrated.

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?

Covers input, output (formatted string), and error handling. With an output schema present, the return format is sufficient. Minor gap: lacks units for output V-speeds or specific performance assumptions.

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 provides a full Args list with clear, concise meanings for all 12 parameters (e.g., 'Takeoff weight in kg'), fully compensating for the schema gap.

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 'Calculate takeoff field length and V-speeds' which is a specific verb+resource. It distinguishes from siblings like 'landing_performance' by specifying takeoff.

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 mentions 'for educational purposes' implying a use case but does not explicitly state when to use this tool vs alternatives like 'get_aircraft_performance' or 'landing_performance'. No exclusions or alternatives are provided.

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

trajectory_sensitivity_analysisA

Perform sensitivity analysis on rocket trajectory parameters.

Args: rocket_geometry: Baseline rocket geometry parameter_variations: Parameters to vary and their ranges analysis_options: Optional analysis settings

Returns: JSON string with sensitivity analysis results showing how each parameter variation affects the trajectory outcome.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
rocket_geometryYes
parameter_variationsYes
analysis_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that errors are returned as formatted strings (no exceptions raised), which is key behavioral info. However, it does not explicitly state the tool is read-only or safe for repeated calls, but the nature of analysis implies no side effects. The error handling disclosure is valuable.

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 moderately concise and well-structured with 'Args', 'Returns', and 'Raises' sections. It avoids fluff and adds value through structured documentation, though the docstring format slightly increases length. Overall, efficient.

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 complexity (3 parameters, nested objects, no annotations) and rich sibling set, the description covers basic purpose and return format but omits input structure details. An output schema exists but is not described. The description is adequate for simple use but lacks depth for correct 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%, requiring the description to compensate. The description provides minimal one-line comments for each parameter (e.g., 'Baseline rocket geometry,' 'Parameters to vary and their ranges'), but lacks details on expected structure, required keys, or formats. For complex objects like 'rocket_geometry', this is insufficient.

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 'Perform sensitivity analysis on rocket trajectory parameters,' using a specific verb and resource. It distinguishes from siblings like 'rocket_3dof_trajectory' (which runs a trajectory) and 'monte_carlo_uncertainty_analysis' (probabilistic), making the purpose unambiguous.

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 use for understanding parameter impact on trajectory, but provides no explicit guidance on when to use this tool versus alternatives like 'monte_carlo_uncertainty_analysis' or 'optimize_launch_angle'. No when-not-to-use or exclusion criteria are given.

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

transform_framesA

Transform coordinates between reference frames (ECEF, ECI, ITRF, GCRS, GEODETIC).

Args: coordinates: Dict with coordinate data (format depends on frame) from_frame: Source reference frame to_frame: Target reference frame epoch_utc: Optional epoch for time-dependent transformations (ISO format)

Returns: JSON string with transformed coordinates in the target frame.

Raises: No exceptions are raised directly; errors are returned as formatted strings. ImportError is caught when required frame transformation packages are missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
coordinatesYes
from_frameYes
to_frameYes
epoch_utcNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that errors are returned as strings, ImportError is caught, and the epoch is optional. It does not explicitly state read-only nature, but the function is clearly a pure transformation.

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 front-loaded with a clear one-sentence purpose, followed by concise Args/Returns/Raises sections. No unnecessary words; every sentence adds value.

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 presence of an output schema (not shown but indicated), the description adequately covers purpose, parameters, and error handling. It could be improved by noting that this tool subsumes specific sibling converters, but overall it is complete.

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 coverage is 0%, so description compensates well. It explains coordinates as a dict with format dependent on frame, from/to frames as source/target, and epoch_utc as optional ISO format. This adds meaningful context beyond the schema's enums and generic object.

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 transforms coordinates between specific reference frames (ECEF, ECI, ITRF, GCRS, GEODETIC), using a specific verb (Transform) and resource (coordinates). It distinguishes from siblings like ecef_to_geodetic by covering all listed frames.

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 coordinate transformation between any of the listed frames but does not explicitly differentiate from specific sibling converters (e.g., ecef_to_geodetic). No when-not-to-use or alternative recommendations are provided.

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

true_airspeed_converterA

Convert between IAS, CAS, EAS, TAS, and Mach number.

Args: speed_value: Input speed value (knots for airspeeds, dimensionless for Mach) speed_type: Input type - "IAS", "CAS", "EAS", "TAS", or "MACH" altitude_ft: Pressure altitude in feet temperature_c: Outside air temperature in Celsius (uses ISA if not provided) position_error_kts: Position error correction in knots (IAS to CAS)

Returns: Formatted string with all equivalent airspeeds (IAS, CAS, EAS, TAS, Mach), dynamic pressure, and atmospheric conditions.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
speed_valueYes
speed_typeYes
altitude_ftYes
temperature_cNo
position_error_ktsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description details the conversion process, input constraints (e.g., units), and the return format (formatted string with all equivalents). It also notes that no exceptions are raised directly, providing transparency on error handling.

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 structured with a clear docstring format listing arguments, returns, and raises. It is moderately concise with no wasted sentences, though some lines (e.g., the raises note) could be integrated.

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?

For a 5-parameter tool with an output schema, the description covers all inputs, explains the return value comprehensively, and mentions error handling. It fully addresses the complexity of airspeed conversions, leaving no major gaps.

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?

The description explains each parameter with units and allowed values (e.g., 'speed_type' enum values, 'altitude_ft' in feet, 'temperature_c' optional with ISA default). Since the input schema has 0% description coverage, the docstring adds essential meaning beyond the raw 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 specifies the verb 'Convert' and the exact resources ('IAS, CAS, EAS, TAS, and Mach number'). This is a specific and distinct functionality among siblings, which include other aerospace calculators but not an airspeed converter.

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 explains what the tool does but does not explicitly state when to use it versus alternatives. Since there is no sibling tool for airspeed conversion, the context is implicit, but lack of usage scenarios or prerequisites reduces clarity.

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

uav_energy_estimateA

Estimate UAV flight time and energy consumption for mission planning.

Args: uav_config: UAV configuration parameters battery_config: Battery configuration parameters mission_profile: Optional mission profile parameters

Returns: Formatted string with energy analysis results including flight time, range, hover time, power required, and efficiency metrics.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
uav_configYes
battery_configYes
mission_profileNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that no exceptions are raised directly (errors returned as formatted strings) and specifies the return type (formatted string with results). This adds useful behavioral context beyond the schema.

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 concise and well-structured with Args, Returns, and Raises sections. Every sentence is informative with no unnecessary words.

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 (3 params, nested objects, return is a formatted string), the description covers purpose, parameters, return value, and error handling. It is nearly complete, though more detail on parameter structure would improve it.

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 provides brief descriptions for each parameter (e.g., 'UAV configuration parameters') but lacks detail on the fields within these nested objects, limiting its value.

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 function: 'Estimate UAV flight time and energy consumption for mission planning.' This is specific and distinguishes it from sibling tools like airfoil_polar_analysis or calculate_distance.

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 use for mission planning but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.

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

weight_and_balanceA

Calculate aircraft center of gravity and verify within limits.

Args: basic_empty_weight_kg: Basic empty weight in kg basic_empty_arm_m: Basic empty weight CG arm (from datum) in meters fuel_kg: Fuel load in kg fuel_arm_m: Fuel tank CG arm in meters payload_items: List of payload items, each with keys: - weight_kg: Weight in kg - arm_m: CG arm in meters - name: Item name (optional) forward_cg_limit_m: Forward CG limit (optional) aft_cg_limit_m: Aft CG limit (optional) max_takeoff_weight_kg: Maximum takeoff weight (optional) mac_m: Mean aerodynamic chord length (optional, for %MAC calculation) lemac_m: Leading edge of MAC position (optional, for %MAC calculation)

Returns: Formatted string with weight and balance calculation results.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
basic_empty_weight_kgYes
basic_empty_arm_mYes
fuel_kgYes
fuel_arm_mYes
payload_itemsYes
forward_cg_limit_mNo
aft_cg_limit_mNo
max_takeoff_weight_kgNo
mac_mNo
lemac_mNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

The description discloses that errors are returned as formatted strings and no exceptions are raised. It also explains the return type (formatted string). Given no annotations, this provides adequate transparency for a calculation tool.

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 front-loaded with purpose and well-structured with parameter list and return info. It is slightly verbose but not wasteful, earning a high score.

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?

All required parameters are explained, optional parameters are documented with defaults, and return value is described. Given the tool's complexity (10 params), the description is complete.

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?

Despite 0% schema description coverage, the description provides detailed documentation for each parameter, including units and optional keys for payload_items. This fully compensates for the schema's lack of descriptions.

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 calculates aircraft center of gravity and verifies limits. The verb 'calculate' and resource 'aircraft center of gravity' are specific, and the tool is distinct from sibling tools like takeoff_performance or landing_performance.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no indication of scenarios where weight_and_balance is preferred over other tools like takeoff_performance.

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

wind_model_simpleA

Calculate wind speeds at different altitudes using logarithmic or power law models.

Args: altitudes_m: List of altitudes in meters surface_wind_speed_ms: Wind speed at 10m reference height in m/s surface_wind_direction_deg: Wind direction at surface in degrees (0=North, 90=East) model_type: Wind model type ('logarithmic' or 'power_law') roughness_length_m: Surface roughness length in meters

Returns: Formatted string with wind profile data at each requested altitude.

Raises: No exceptions are raised directly; errors are returned as formatted strings.

Note: The logarithmic wind profile (Ref: Stull, "Meteorology for Scientists and Engineers", 2000) models wind speed as: U(z) = (u* / kappa) * ln(z / z0) where u* is friction velocity, kappa ~0.4 is the von Karman constant, and z0 is the aerodynamic roughness length.

The **power-law wind profile** (empirical approximation) models wind as:
    U(z) = U_ref * (z / z_ref) ^ alpha
where alpha (Hellmann exponent) depends on terrain roughness, typically
~0.14 for open terrain and ~0.40 for urban areas.
ParametersJSON Schema
NameRequiredDescriptionDefault
altitudes_mYes
surface_wind_speed_msNo
surface_wind_direction_degNo
model_typeNologarithmic
roughness_length_mNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Details the two models with formulas and references, and states that errors are returned as formatted strings (no exceptions). With no annotations, this covers key behavioral aspects adequately.

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?

Well-structured with sections for args, returns, raises, and notes. Contains necessary formulas, but could be trimmed slightly without losing clarity.

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?

Covers purpose, parameters, error handling, and references. With an output schema present (per context), not needing full return description. Lacks examples or typical usage scenarios.

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?

Despite 0% schema description coverage, the description independently explains all 5 parameters with units and context (e.g., 'Wind speed at 10m reference height', model_type enum explained).

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?

Clearly states it calculates wind speeds at different altitudes using specific models (logarithmic or power law). Distinguishes from siblings like get_atmosphere_profile by focusing on wind only.

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?

No guidance on when to use this tool versus alternative tools like get_atmosphere_profile or density_altitude_calculator. Lacks 'when not to use' or explicit context for selection.

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

wing_vlm_analysisA

Analyze wing aerodynamics using Vortex Lattice Method or simplified lifting line theory.

Args: wing_config: Wing configuration with keys: - span_m: Wing span in meters - chord_root_m: Root chord in meters - chord_tip_m: Tip chord in meters (optional, defaults to chord_root_m) - sweep_deg: Quarter-chord sweep in degrees (optional, default 0) - dihedral_deg: Dihedral angle in degrees (optional, default 0) - twist_deg: Tip twist in degrees (optional, default 0) - airfoil_root: Root airfoil name (optional, default 'NACA2412') - airfoil_tip: Tip airfoil name (optional, default matches root) flight_conditions: Flight conditions with keys: - alpha_deg_list: List of angles of attack to analyze (required) - mach: Mach number (optional, default 0.2) - reynolds: Reynolds number (optional) analysis_options: Optional analysis settings (currently unused)

Returns: Formatted string with aerodynamic analysis results including CL, CD, CM, and L/D ratio at each angle of attack.

Raises: No exceptions are raised directly; errors are returned as formatted strings. ImportError is caught when aerodynamics packages are not installed.

Note: The Vortex Lattice Method (VLM) discretizes the wing planform into panels, each modeled with a horseshoe vortex. Each horseshoe vortex consists of a bound vortex along the panel quarter-chord line and two trailing (semi-infinite) vortices extending downstream. The induced velocity at each panel's 3/4-chord control point is computed via the Biot-Savart law, and the no-penetration boundary condition is enforced to solve for the vortex strengths (circulation distribution).

ParametersJSON Schema
NameRequiredDescriptionDefault
wing_configYes
flight_conditionsYes
analysis_optionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

The description discloses that errors are returned as formatted strings and that ImportError is caught. It explains the VLM theory, which adds useful context beyond the schema. However, it doesn't mention side effects, performance constraints, or whether the tool is read-only. With no annotations, the description partially covers behavioral aspects but has gaps.

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 (Args, Returns, Raises, Note). It is somewhat verbose with the VLM technical explanation, but that adds educational value. Overall, it is reasonably concise and front-loaded with key information.

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 complexity and the presence of an output schema (formatted string), the description adequately explains return format and error handling. It covers parameter details thoroughly. Minor improvement would be to include example output or units, but current content is sufficient for interpretation.

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?

Schema description coverage is 0%, yet the description compensates by detailing all keys, their types, defaults, and optionality for wing_config and flight_conditions. It adds significant meaning beyond the raw schema, which only defines top-level object types. This strongly helps an agent understand parameter usage.

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 analyzes wing aerodynamics using VLM or lifting line theory. It specifies the resource (wing configuration) and distinguishes from sibling tools like airfoil_polar_analysis or propeller_bemt_analysis, which focus on different aspects.

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 does not provide explicit guidance on when to use this tool over alternatives. It mentions two methods (VLM and lifting line) but doesn't explain when to choose one. No when-not-to-use or sibling comparisons are included.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 12 tool updatesv0.0.2
    • Addeddensity_altitude_calculator
    • Addedfuel_reserve_calculator
    • Addedkalman_filter_state_estimation
    • Addedlambert_problem_solver
    • Addedlanding_performance
    • Addedlist_tool_categories
    • Addedlqr_controller_design
    • Addedsearch_aerospace_tools
    • Addedstall_speed_calculator
    • Addedtakeoff_performance
    • Addedtrue_airspeed_converter
    • Addedweight_and_balance
  2. 34 tool updatesv1.0.0
    • Addedairfoil_polar_analysis
    • Changedcalculate_distance9 fields changed
      • removedInput schema / properties / destination
        Removed value: -{
-  "properties": {
-    "latitude": {
-      "maximum": 90,
-      "minimum": -90,
-      "type": "number"
-    },
-    "longitude": {
-      "maximum": 180,
-      "minimum": -180,
-      "type": "number"
-    }
-  },
-  "required": [
-    "latitude",
-    "longitude"
-  ],
-  "type": "object"
-}
      • addedInput schema / properties / lat1
        Added value: +{
+  "title": "Lat1",
+  "type": "number"
+}
      • addedInput schema / properties / lat2
        Added value: +{
+  "title": "Lat2",
+  "type": "number"
+}
      • addedInput schema / properties / lon1
        Added value: +{
+  "title": "Lon1",
+  "type": "number"
+}
      • addedInput schema / properties / lon2
        Added value: +{
+  "title": "Lon2",
+  "type": "number"
+}
      • removedInput schema / properties / origin
        Removed value: -{
-  "properties": {
-    "latitude": {
-      "maximum": 90,
-      "minimum": -90,
-      "type": "number"
-    },
-    "longitude": {
-      "maximum": 180,
-      "minimum": -180,
-      "type": "number"
-    }
-  },
-  "required": [
-    "latitude",
-    "longitude"
-  ],
-  "type": "object"
-}
      • removedInput schema / properties / step_km
        Removed value: -{
-  "default": 50,
-  "description": "Step size for polyline generation in km",
-  "minimum": 1,
-  "type": "number"
-}
      • changedInput schema / required
        Previous value: -[
-  "origin",
-  "destination"
-]New value: +[
+  "lat1",
+  "lon1",
+  "lat2",
+  "lon2"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "_WrappedResult",
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedcalculate_ground_track
    • Addedcalculate_stability_derivatives
    • Addedecef_to_geodetic
    • Addedelements_to_state_vector
    • Addedestimate_rocket_sizing
    • Addedformat_data_for_tool
    • Addedgenetic_algorithm_optimization
    • Addedgeodetic_to_ecef
    • Changedget_aircraft_performance9 fields changed
      • removedInput schema / properties / aircraft_type / description
        Removed value: -"ICAO aircraft type code (e.g., 'A320', 'B738')"
      • addedInput schema / properties / aircraft_type / title
        Added value: +"Aircraft Type"
      • removedInput schema / properties / cruise_altitude
        Removed value: -{
-  "default": 35000,
-  "description": "Cruise altitude in feet",
-  "maximum": 45000,
-  "minimum": 8000,
-  "type": "integer"
-}
      • addedInput schema / properties / cruise_altitude_ft
        Added value: +{
+  "default": 35000,
+  "title": "Cruise Altitude Ft",
+  "type": "number"
+}
      • removedInput schema / properties / distance_km / description
        Removed value: -"Route distance in kilometers"
      • removedInput schema / properties / distance_km / minimum
        Removed value: -1
      • addedInput schema / properties / distance_km / title
        Added value: +"Distance Km"
      • removedInput schema / properties / mass_kg
        Removed value: -{
-  "description": "Aircraft mass in kg (optional)",
-  "type": "number"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "_WrappedResult",
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedget_airfoil_database
    • Addedget_atmosphere_profile
    • Addedget_propeller_database
    • Changedget_system_status2 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "_WrappedResult",
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedhohmann_transfer
    • Addedmonte_carlo_uncertainty_analysis
    • Addedoptimize_launch_angle
    • Addedoptimize_thrust_profile
    • Addedorbital_rendezvous_planning
    • Addedparticle_swarm_optimization
    • Changedplan_flight21 fields changed
      • addedInput schema / properties / aircraft / anyOf
        Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / aircraft / default
        Added value: +null
      • removedInput schema / properties / aircraft / properties
        Removed value: -{
-  "cruise_altitude": {
-    "default": 35000,
-    "description": "Cruise altitude in feet",
-    "maximum": 45000,
-    "minimum": 8000,
-    "type": "integer"
-  },
-  "mass_kg": {
-    "description": "Aircraft mass in kg (optional, uses 85% MTOW if not specified)",
-    "type": "number"
-  },
-  "type": {
-    "description": "ICAO aircraft type (e.g., 'A320', 'B738', 'A359')",
-    "type": "string"
-  }
-}
      • removedInput schema / properties / aircraft / required
        Removed value: -[
-  "type"
-]
      • addedInput schema / properties / aircraft / title
        Added value: +"Aircraft"
      • removedInput schema / properties / aircraft / type
        Removed value: -"object"
      • addedInput schema / properties / arrival / additionalProperties
        Added value: +true
      • removedInput schema / properties / arrival / properties
        Removed value: -{
-  "city": {
-    "description": "Arrival city name",
-    "type": "string"
-  },
-  "country": {
-    "description": "Arrival country code (optional)",
-    "type": "string"
-  },
-  "iata": {
-    "description": "Preferred arrival IATA code (optional)",
-    "type": "string"
-  }
-}
      • removedInput schema / properties / arrival / required
        Removed value: -[
-  "city"
-]
      • addedInput schema / properties / arrival / title
        Added value: +"Arrival"
      • addedInput schema / properties / departure / additionalProperties
        Added value: +true
      • removedInput schema / properties / departure / properties
        Removed value: -{
-  "city": {
-    "description": "Departure city name",
-    "type": "string"
-  },
-  "country": {
-    "description": "Departure country code (optional)",
-    "type": "string"
-  },
-  "iata": {
-    "description": "Preferred departure IATA code (optional)",
-    "type": "string"
-  }
-}
      • removedInput schema / properties / departure / required
        Removed value: -[
-  "city"
-]
      • addedInput schema / properties / departure / title
        Added value: +"Departure"
      • addedInput schema / properties / route_options / anyOf
        Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / route_options / default
        Added value: +null
      • removedInput schema / properties / route_options / properties
        Removed value: -{
-  "step_km": {
-    "default": 25,
-    "description": "Distance between polyline points in km",
-    "minimum": 1,
-    "type": "number"
-  }
-}
      • addedInput schema / properties / route_options / title
        Added value: +"Route Options"
      • removedInput schema / properties / route_options / type
        Removed value: -"object"
      • changedInput schema / required
        Previous value: -[
-  "departure",
-  "arrival",
-  "aircraft"
-]New value: +[
+  "departure",
+  "arrival"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "_WrappedResult",
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedporkchop_plot_analysis
    • Addedpropagate_orbit_j2
    • Addedpropeller_bemt_analysis
    • Addedrocket_3dof_trajectory
    • Changedsearch_airports10 fields changed
      • addedInput schema / properties / country / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / country / default
        Added value: +null
      • removedInput schema / properties / country / description
        Removed value: -"Optional ISO country code to filter by (e.g., 'US', 'JP')"
      • addedInput schema / properties / country / title
        Added value: +"Country"
      • removedInput schema / properties / country / type
        Removed value: -"string"
      • removedInput schema / properties / query / description
        Removed value: -"IATA code (e.g., 'SJC') or city name (e.g., 'San Jose')"
      • addedInput schema / properties / query / title
        Added value: +"Query"
      • removedInput schema / properties / query_type / description
        Removed value: -"Type of query - 'iata' for IATA codes, 'city' for city names, 'auto' to detect"
      • addedInput schema / properties / query_type / title
        Added value: +"Query Type"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "_WrappedResult",
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedselect_aerospace_tool
    • Addedstate_vector_to_elements
    • Addedtrajectory_sensitivity_analysis
    • Addedtransform_frames
    • Addeduav_energy_estimate
    • Addedwind_model_simple
    • Addedwing_vlm_analysis
  3. 5 tool updates
    • First observedcalculate_distance
    • First observedget_aircraft_performance
    • First observedget_system_status
    • First observedplan_flight
    • First observedsearch_airports
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 46 tools

Disambiguation4/5

Tools are generally distinct with clear descriptions, but there are several overlapping categories (e.g., multiple optimization methods, multiple orbital mechanics tools) that could cause confusion if descriptions are not read carefully.

Naming Consistency2/5

Tool names follow inconsistent patterns: some start with verbs (calculate_, get_, search_), others with nouns (airfoil_polar_analysis, hohmann_transfer). Underscores are used but no uniform verb_noun structure, making it harder to predict tool names.

Tool Count3/5

46 tools is high for a single server, covering a very broad domain. Includes several meta-tools (format_data_for_tool, select_aerospace_tool) that inflate the count. Could be streamlined, but many tools are necessary for the wide scope.

Completeness4/5

Covers most key aerospace domains: airfoil, wing, propeller, aircraft performance, rocket trajectory, orbital mechanics, coordinate transforms, atmospheric models, etc. Missing some niche areas but overall very comprehensive.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches