The aerospace-mcp server defines 12 tools with consistent verb-based naming and documented input schemas. However, descriptions are terse, output schemas are undocumented, and parameter descriptions lack the depth required for LLM reasoning. The server demonstrates domain expertise in aerospace but falls short of production-grade tool clarity standards. Average tool score: 58/100.
Tools (12)
calculate_distanceread onlysource verified70/100
Calculate great-circle distance between airports
convert_unitsread onlysource verified77/100
Convert values between aerospace units (length, speed, mass, pressure, temperature, angle)
geodetic_to_ecefread onlysource verified72/100
Convert geodetic coordinates (lat/lon/alt) to ECEF
Output schemas completely undocumented for all 12 tools. LLMs cannot know what fields to extract, what types to expect, or how to chain results to subsequent tools.
Parameter descriptions are terse and lack actionable constraints. Examples: plan_multi_leg_flight states '2-10 waypoints' in description rather than enforced minItems/maxItems; convert_units lists supported domains inline without defining supported unit pairs; wind_model_simple does not specify surface_roughness_m valid range.
Add documented output schemas for all 12 tools. Example for search_airports: 'Returns: {airports: [{iata: string, city: string, country: string, name: string, lat: number, lon: number}], total: number}'. Use the same pattern for all tools so LLM can predict structure.
Convert parameter enums from description text to explicit JSON Schema enum constraints. Example: transform_frames.source_frame should be {'type': 'string', 'enum': ['ECEF', 'ECI', 'ITRF', 'GCRS', 'GEODETIC'], 'description': 'Source reference frame...'}.
Expand tool descriptions to 150-250 characters by adding guidance on when to use each tool and what data is returned. Example for plan_flight: 'Plan a flight route between two airports with performance estimates (fuel burn, time-to-climb, cruise time, descent time). Use this for single-leg flights; for multi-leg journeys, use plan_multi_leg_flight.'
Add error recovery guidance to tool descriptions. Example for convert_units: 'Returns error if unit pair is unsupported. Valid unit pairs: (kts, mps, kmh), (ft, m, mi), (kg, lb). For unsupported conversions, call search_units_database() first to discover compatible pairs.'
Fix geodetic_to_ecef schema to include altitude_deg as input parameter. Clarify whether altitude defaults to 0 or is required.
Score history
Overall score trend
↑ 28 points across a rubric change (v1 → v2)
54/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
54
2026-07-28+
v2
2026-03-09
F
26
-
v1
plan_flight
read onlysource verified67/100
Plan a flight route between two airports with performance estimates
Tool descriptions are under 100 characters for 7 of 12 tools (get_aircraft_database, plan_multi_leg_flight, get_system_status, wind_model_simple, transform_frames). They lack context on when to use each tool vs. similar ones, what data is returned, or dependency relationships.
geodetic_to_ecef input schema is incomplete. Description mentions 'lat/lon/alt' but input definition shown only includes latitude_deg and longitude_deg. Altitude is missing, creating a functional gap that will cause tool failures.
No error handling or recovery guidance. Tools do not document failure modes (invalid units, out-of-range altitudes, missing airports) or guide LLMs on next steps. LLMs cannot self-correct on invalid input.
Nested object parameters (departure, arrival in plan_flight; origin, destination in calculate_distance) lack explicit schema documentation. Required vs. optional fields are unclear; LLM must guess structure.
Enum-like parameters are documented in descriptions rather than enforced as JSON Schema enums. Examples: get_aircraft_database 'substring filter or exact ICAO', get_atmosphere_profile 'isa' or 'enhanced', wind_model_simple 'logarithmic' or 'power_law'. LLMs cannot reliably parse loose description text and will hallucinate invalid options.
Add parameter bounds and constraints. Examples: plan_multi_leg_flight.waypoints minItems=2, maxItems=10; wind_model_simple.surface_roughness_m between 0.001 and 2.0 (typical range for various terrains).
Document expected units and precision for numeric outputs. Example for calculate_distance: 'Returns: {distance_m: number (meters, ±10m precision), distance_km: number, polyline: string (GeoJSON LineString)}.'
Group related tools with cross-references in descriptions to guide LLM routing. Example: search_airports description: 'For flight planning, see plan_flight. For multi-leg routes, see plan_multi_leg_flight.'
Add state-of-data disclaimers for airport database tools (e.g., 'Database updated monthly; inactive/closed airports may be included'). LLMs need to know data freshness and edge cases.