Loading ToolBench
Model Context Protocol server for e2m2e (Earth to Moon, Moon to Earth) — a cislunar astrodynamics and trajectory design toolkit. Exposes Facade methods as MCP tools for LLM agents via stdio transport.
Single tool 'catalog_query' with comprehensive schema and reasonable description. However, description is generic and could better explain when/why to use it. Schema is well-formed with 15 parameters covering orbit family, libration point, Jacobi constant bounds, amplitude bounds, mission profile (CR3BP vs ephemeris), transfer types, delta-v ranges, TLI epochs, status, and tags. All parameters are typed and have descriptions (meets baseline of 100% of A+ tools requiring param descriptions). Tool name 'catalog_query' starts with verb but is somewhat generic, 'search_orbits' or 'query_transfer_catalog' would be more action-specific. Output schema not documented in the visible source. No evidence of pagination support despite the query-heavy nature of a catalog tool. Error handling and recovery guidance absent from description.
Query the orbit catalog by filtering dimensions (family, Jacobi constant, amplitude, transfer type, etc.). Returns matching catalog records.
Tool name 'catalog_query' is generic. Verb 'query' does not clearly distinguish action intent. Should be 'search_orbits', 'filter_transfer_catalog', or 'find_transfer_opportunities' for clarity.
Description lacks WHEN/WHY context. Current description 'Query the orbit catalog by filtering dimensions...' is functional but does not explain when an LLM should call this tool vs alternatives, what the typical use case is, or what downstream tools consume its output.
Output schema is not documented. Source code shows input schema clearly but no return type, fields, or structure for query results. LLMs cannot plan downstream tool calls without knowing what fields the response contains (e.g., orbit_id, trajectory_data, delta_v_actual, feasibility_status).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
No pagination support visible in schema. A catalog query tool that may return many matching orbits lacks limit, offset, page_size, or cursor parameters. Large unbounded result sets will blow context windows and degrade LLM reasoning.
No error recovery guidance in description. If a query returns no results or invalid parameters are passed, the LLM has no direction on what to try next (e.g., 'expand jacobi_min/max bounds', 'remove restrictive filters', 'try search_orbit_families() first to discover valid families').
Parameter 'transfer_type' accepts a string but no enum or constraint is documented. Source shows example 'TLI', 'MCC', 'LOI' in description, but these are presented as examples (which LLMs tend to reuse literally) rather than a formal enum. Should be constrained to valid options.
Parameter 'status' accepts a string with example 'success', 'rejected' but no formal enum or exhaustive list of valid values provided. LLM will guess at valid status strings.
Parameter descriptions could specify expected ranges more clearly. E.g., 'jacobi_min' description says 'Minimum Jacobi constant (interval filter lower bound)' but does not state typical range (e.g., 2.0 - 3.5 for Earth-Moon system) or units. LLMs will struggle to provide realistic bounds without examples or constraints.