Loading ToolBench
An MCP server that provides real-time astronomical data, smart stargazing planning, and light pollution analysis for AI agents.
The server defines 8 tools with schemas and descriptions present, but exhibits significant gaps in definition quality. All tools have basic descriptions (10-100 chars) and input schemas with typed parameters. However, descriptions are often generic and lack actionable context. Parameter descriptions are minimal (typically 1-2 sentences). Output schemas are not documented anywhere in the provided code. No error handling guidance or recovery instructions visible. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) present. Tool naming follows verb_noun convention (positive), but several tools operate on the same domain (astronomical queries) with subtle naming distinctions that could confuse LLM selection. The fastmcp framework appears to handle schema registration, but validation of actual runtime behavior is not evident from the codebase.
Analyze stargazing suitability for an area with pagination support
Get celestial position for a celestial object
Get rise and set times for a celestial object
Get constellation information for a given location and time
Get local datetime information
Get visible planets for a given location and time
Get weather information for a given position
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, forcing them to parse unstructured output. This violates the schema documentation requirement and increases hallucination risk.
Tool descriptions lack actionable context. 'Get local datetime information' (23 chars) does not explain WHEN to call it, what it returns, or why an LLM would need it. Most descriptions are 30-60 chars, below the 50-200 char baseline for LLM-optimized tool descriptions.
Parameter descriptions are minimal (e.g., 'Longitude' for the 'lon' parameter). Missing expected format, range constraints (e.g., -180 to 180 for longitude), and dependency documentation (e.g., 'lon and lat must be provided together').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 60 | 2024-11-25+ | v1 |
Get light pollution data for a geographic area
No error handling guidance or recovery instructions visible in code. If a tool fails (e.g., invalid coordinates, timezone not found), LLMs have no actionable recovery path.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. All 8 tools are READ_ONLY according to the risk field, but this is not encoded in the schema or tool metadata in a way modern MCP clients can parse.
Multiple tools query celestial objects (get_celestial_pos, get_celestial_rise_set) and locations (get_visible_planets, get_constellation, light_pollution_map, analysis_area). Naming is slightly ambiguous, LLMs may struggle to choose between 'get_visible_planets' (returns list?) vs 'get_celestial_pos' (returns position?) without seeing output schemas.
get_local_datetime_info has empty input schema ({}). It cannot accept parameters, but lacks explanation of what it returns or why an LLM would call it. Minimal description (23 chars) violates the 50-200 char baseline.
Time format specified as 'YYYY-MM-DD HH:MM:SS' in descriptions but not enforced in schema (no regex pattern or format constraint visible). LLMs may pass '2024-1-5 9:30:00' or '01/05/2024 9:30 AM' without validation guidance.