Loading ToolBench
MCP server for satellite orbit calculation, prediction, and observation simulation
The server provides 14 tools for satellite orbit calculations and visualization. While most tools have descriptions and some parameter documentation, critical gaps exist: (1) Many parameter descriptions lack format/constraint details, e.g. 'start_time' accepts 'YYYY MM DD HH MM SS.SSS' but description doesn't clarify spacing requirements vs hyphens. (2) Output schemas are entirely undocumented, no tool shows what fields are returned. (3) Tool names lack action verbs, 'kpl2cts', 'cts2kpl', 'run_orbitPrediction_numerical' are cryptic abbreviations unfamiliar to LLMs. (4) Error handling is not visible, no recovery guidance. (5) The initial_orbit_determination tool accepts a file path but doesn't describe file format expectations. Positive: descriptions are reasonably detailed (100-150 chars typical), some technical depth is present, and parameter types are defined in JSON Schema. This is typical of a specialized domain tool without LLM-optimization.
Convert Cartesian coordinates to Keplerian elements
Convert date to Modified Julian Date
Convert Keplerian elements to Cartesian coordinates
Convert Modified Julian Date to date
Calculate satellite observation data from a ground-based observer
Run orbit prediction using the .exe executable with high-precision numerical integration
Predict satellite orbit using two-body problem dynamics
Tool names use cryptic abbreviations ('kpl2cts', 'cts2kpl', 'run_orbitPrediction_numerical') without action verbs. LLMs cannot infer intent from 'kpl2cts' alone, should be 'convert_keplerian_to_cartesian'.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields if they don't know what the response contains. Example: does 'run_orbitPrediction_numerical' return a file path, success flag, or error message?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Parameter format constraints are unclear. 'start_time' format is described as 'YYYY MM DD HH MM SS.SSS' but does not clarify spacing (spaces vs hyphens). 'date' accepts 'YYYY-MM-DD HH:MM:SS', inconsistent notation. LLMs will struggle with format mismatches.
File path parameters ('data_file', 'filename', 'fn_eph', 'fn_data') lack documentation of expected file formats, encoding, or structure. LLMs will pass invalid paths or incorrect file types, causing silent failures.
'generate_all_styles' and 'list_available_styles' lack substantive descriptions (under 50 chars). Cannot explain when or why LLMs should call these tools.
No error handling or recovery guidance visible in any tool definition. If a file is missing, invalid, or computation fails, LLMs have no guidance on what to do next.
Parameter relationships not documented. Example: 'obs_type' in 'run_satellite_observation' accepts integers 11-19 but no mapping to meaning (e.g. 11=Angles, 12=Radar) is provided. LLMs must guess or hallucinate values.