mcp-stargazing

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct aspect of stargazing: celestial positions, moon/planet info, weather, light pollution, area analysis, and planning. Overlaps are minimal and descriptions clearly differentiate them.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern (get_*, list_*) with snake_case. The few exceptions like 'analysis_area' and 'light_pollution_map' still adhere to the pattern and are descriptive.
Tool Count5/5
15 tools is well-scoped for a stargazing server, covering essential functions without being too many or too few. Each tool serves a clear purpose.
Completeness5/5
The server covers the full stargazing workflow: location analysis, weather, light pollution, celestial positions, visibility, moon/planet info, nightly forecasts, and planning for both casual and astrophotography use.
Average 4/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on July 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions running two internal functions but does not state whether the tool is read-only, has side effects, or requires specific permissions. Insufficient for a mutation-aware agent.
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?
Two sentences that are front-loaded with the core purpose and a brief internal workflow description. No wasted words.
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?
With 16 parameters and no schema descriptions, the description is too sparse to fully inform an agent. Even though an output schema exists, the input parameters remain undocumented, which is a significant gap for a complex astrophotography tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any parameter beyond implicit context (location, time, focal length). Agent has no guidance on parameter meanings or constraints.
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 it generates a single-night astrophotography shooting plan and specifies the returned elements (targets, moon, timed shooting slots). Implicitly differentiates from sibling tools like get_telescope_targets by mentioning it runs two internal processes.
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 or alternatives. Does not mention prerequisites or exclusions, 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.
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 of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify error handling (e.g., invalid object names), computational limits (e.g., date ranges), or authentication requirements. For a calculation tool with 5 required parameters, this leaves significant gaps in understanding how it behaves in 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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured sections for Args and Returns. Every sentence earns its place by providing essential information, though the Returns section could be slightly more concise by omitting obvious keys like '_meta' if not critical.
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 (5 required parameters, no annotations, but with an output schema), the description is moderately complete. The output schema reduces the need to explain return values in detail, but the description lacks context on prerequisites (e.g., valid object names), error cases, or performance considerations, which are important for a calculation tool with multiple inputs.
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 adds meaningful semantics by explaining each parameter: 'celestial_object' with examples ('sun', 'moon', 'andromeda'), 'lon'/'lat' as observer coordinates in degrees, 'time' as a date string with format, and 'time_zone' as IANA string. This clarifies usage beyond the bare schema, though it could benefit from more detail on valid object names or coordinate ranges.
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 with a specific verb ('Calculate') and resource ('rise and set times of a celestial object'). It distinguishes from siblings like 'get_celestial_pos' (position) and 'get_moon_info' (moon-specific details) by focusing on temporal events rather than positional or informational data.
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 doesn't mention sibling tools like 'get_moon_info' (which might include rise/set times for the moon) or 'get_visible_planets' (which might list visible objects), leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns (a dict with specific keys) but doesn't mention whether this is a read-only operation, if it requires authentication, or if there are rate limits. It provides basic output structure but lacks deeper behavioral context.
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 perfectly concise and well-structured: a clear purpose statement followed by return format details. Every sentence earns its place with no wasted words, and the information is front-loaded appropriately for quick understanding.
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 (zero parameters, has output schema), the description is reasonably complete. It explains what the tool does and what it returns, though it could benefit from more behavioral context (like whether it's read-only or has any limitations). The output schema existence reduces the need for detailed return value explanation.
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 (schema coverage 100%), so the description doesn't need to explain any inputs. The baseline for zero parameters is 4, as there's no parameter information to add beyond what the schema already indicates (no properties).
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's purpose with specific verbs ('retrieve') and resources ('current datetime and timezone'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_celestial_pos' or 'get_weather_by_position' that also provide time-related data, which prevents a perfect score.
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. With siblings like 'get_celestial_pos' that might include timezone data, there's no indication of when this specific datetime retrieval is preferred or what its limitations are, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description includes the return format (dict with 'data' and '_meta' keys, data is a list of planet dicts with name, altitude, azimuth) which adds transparency. However, it does not disclose potential side effects, error handling, or limits (e.g., rate limiting, data freshness).
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 one-line purpose followed by a bulleted list for Args and Returns. No redundant words or sentences.
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 existence of an output schema, the description does not need to explain return values in full detail but still provides a helpful overview. The tool has 4 required parameters with clear descriptions. Minor improvement: could mention that only planets are included, or what altitude/azimuth mean, but overall adequate.
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 provides meaningful parameter explanations beyond the input schema, including units for lon/lat (degrees), time format (YYYY-MM-DD HH:MM:SS), and timezone type (IANA). This compensates for the 0% schema description coverage. Each parameter is clearly described in the Args section.
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 a list of solar system planets currently visible above horizon, using a specific verb 'get' and resource 'list of solar system planets'. This distinguishes it from sibling tools like get_celestial_pos which likely retrieves positions of arbitrary celestial objects.
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 usage guidelines are provided. The description does not mention when to use this tool vs alternatives, nor any prerequisites or conditions. For example, it does not clarify that this tool only returns planets (not stars or other objects) or that it requires valid observer coordinates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 combining three tools and returns a dict with 'data' and '_meta', but does not disclose potential side effects, required permissions, or failure modes. It adds behavioral context but lacks completeness.
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 summary, list of combined tools, and parameter breakdown. It front-loads the core purpose. Though lengthy, it is appropriately sized for a complex tool with 14 parameters.
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 complexity (14 parameters, no annotations) and presence of an output schema, the description adequately explains the tool's function, inputs, and return structure. It lacks examples or edge cases but is sufficiently complete for an AI agent.
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%, yet the description includes an 'Args:' section with brief explanations for all 14 parameters (e.g., 'Bounding box coordinates', 'IANA timezone string'). This adds meaning beyond the schema, but descriptions are minimal and do not elaborate on defaults or dependencies.
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: 'Create a composite stargazing plan for a region and time.' It specifies the combination of three sub-tools, making it distinct from sibling tools like get_weather_by_position or get_nightly_forecast. The verb 'create' and resource 'composite stargazing plan' are precise.
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 usage through its composite nature, but does not explicitly state when to use this tool versus alternatives like analysis_area or get_nightly_forecast individually. It provides context by listing what it combines, offering implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not behavioral traits. It doesn't disclose whether calculations are approximate vs precise, what coordinate system is used, error handling, or performance characteristics. For a calculation tool with 5 parameters, this leaves significant behavioral 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?
Perfectly structured with purpose statement, parameter explanations, and return format - all in minimal sentences. Every element earns its place with no redundancy. The Args/Returns sections are appropriately formatted.
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 calculation complexity and 5 parameters with no annotations, the description does well with parameter semantics and output explanation. However, it lacks context about calculation methods, precision, or limitations. The presence of an output schema (implied by Returns section) helps but doesn't fully compensate for missing behavioral context.
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 providing clear semantics for all 5 parameters: object name examples, coordinate units (degrees), time format, and timezone standard. This adds substantial value beyond 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 the specific verb 'calculate' and the exact resource 'altitude and azimuth angles of a celestial object'. It distinguishes from siblings like 'get_celestial_rise_set' (rise/set times) and 'get_constellation' (constellation identification) by focusing on positional 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 implies usage when altitude/azimuth calculations are needed, but provides no explicit guidance on when to choose this tool versus alternatives like 'get_visible_planets' or 'get_celestial_rise_set'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the return type (grid of data points) but does not disclose other behavioral aspects like rate limits, required permissions, or read-only nature. Since no annotations exist, the description should provide more context.
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 succinct, with a clear purpose sentence followed by parameter explanations. No superfluous content.
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 all parameters and indicates the output data types. With an output schema present, it does not need to detail return structure further. Minor omission: coordinate system not specified.
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 the bounding box parameters and the zoom default, compensating for the 0% schema description coverage. It adds meaning beyond the schema by stating 'Bounding box coordinates' and the effect of higher zoom.
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 light pollution data for an area and lists the data points (brightness, Bortle class, SQM). It is distinct from sibling tools which focus on celestial positions, weather, etc.
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. It only states what it does, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that providing lat/lon enhances output with local altitude/azimuth, and specifies return dict structure. Without annotations, this provides adequate behavioral context, though no mention of error conditions or rate 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 separate sections for intro, parameter explanations, and return info. Slightly verbose in places but overall efficient and front-loaded with 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?
Covers all key aspects: purpose, parameters, optional behavior, and return structure. With output schema present, the description is sufficiently complete for a tool with moderate complexity.
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 coverage, description fully compensates by providing format (YYYY-MM-DD HH:MM:SS), type (IANA timezone), purpose (observer lat/lon for local position), and optionality. Adds meaning 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 verb 'Get' and resource 'detailed information about the Moon's phase and position', distinguishing it from sibling tools like get_celestial_pos which cover other celestial bodies.
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?
Implies use when moon data is needed, but does not explicitly contrast with alternatives (e.g., get_celestial_rise_set for rise/set times, list_visible_planets for planets). 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the aggregation and fallback behavior, and the return structure with success and error keys. With no annotations, this provides useful transparency, though it lacks details on data freshness, units, or rate 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?
The description is moderately concise with a clear summary line and structured Args/Returns sections. It avoids verbosity, though the mix of languages and detailed sections adds some 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 output schema, the description covers return values and error structure. It explains key behavioral aspects and parameters. Minor gaps remain (coordinate range, units), but overall adequate for a weather 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 0% description coverage, but the description explains each parameter: lat/lon as coordinates and provider with possible values (all/qweather/open-meteo/wttr), fully compensating 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 verb 'get' and the resource 'weather by position', and specifies the scope (current, hourly, daily) and aggregation with fallback. It distinguishes from siblings like get_weather_by_name which is for city names.
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-based queries and notes that open-meteo requires no API key, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tool get_weather_by_name exists but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the responsibility. It discloses the tool is a read operation returning altitude, azimuth, and metadata. It does not mention edge cases or error handling, but the return structure is clearly stated and aligns with typical query tools.
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 with a clear Purpose line, followed by structured Args and Returns sections. Every sentence adds value without redundancy, and it is well 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?
Given the tool's moderate complexity (5 params, no annotations, output schema exists), the description covers inputs and output adequately. It lacks guidance on default values or error scenarios, but the output schema presumably fills in return details. Sibling differentiation is missing.
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 defines all 5 parameters with examples (e.g., 'Orion', degrees format, ISO time, IANA timezone). This adds significant meaning beyond the bare 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 the tool retrieves the position (altitude/azimuth) of a constellation center. It specifies the verb 'Get' and the resource 'position', distinguishing it from siblings like get_celestial_pos or list_visible_planets which target different celestial objects or properties.
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 inputs and output but does not explicitly guide when to use this tool versus alternatives like get_celestial_pos or get_celestial_rise_set. Usage is implied by the constellation-specific focus, but no conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool returns a ranked list with suitability scores and describes the output structure. However, it does not mention any side effects, authentication needs, rate limits, or limitations (e.g., dependency on input accuracy). The behavioral transparency is good but not exhaustive.
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, then 'Args' and 'Returns' sections. It is somewhat lengthy due to the detailed parameter list, but every sentence adds value. The front-loading of the purpose sentence is good. Minor redundancy could be trimmed, but overall it is appropriately sized for a complex tool.
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 (15 parameters, no schema descriptions, no annotations, but with an output schema), the description is remarkably complete. It explains all parameters, the return value structure with key fields (suitability_score, fov_fit_score, etc.), and assumes the output schema covers additional details. It lacks error handling guidance but meets the bar for a recommendation 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 0% description coverage, but the description provides detailed, clear explanations for every parameter, including examples (e.g., 'focal_length_mm: Telescope focal length in mm (e.g. 250 for RedCat51)') and context. This adds significant meaning beyond the schema's type/default information, fully compensating for the lack of 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 clearly states the tool's purpose: 'Recommend astrophotography targets for a telescope setup.' It uses a specific verb ('Recommend') and specifies the resource ('astrophotography targets for a telescope setup'). Among sibling tools like 'get_best_stargazing_plan' and 'get_shooting_plan', this tool's focus on telescope-specific recommendations distinguishes it well.
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 context (when you have a telescope setup and want target recommendations) but does not provide explicit guidance on when to use this tool versus siblings like 'get_best_stargazing_plan' or 'get_shooting_plan'. No exclusions or alternatives are mentioned, which leaves some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return structure (dict with 'data' and '_meta' keys), which adds transparency. However, it does not mention potential limitations or safety aspects.
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: two sentences, front-loaded with the primary purpose, and no wasted words. Every sentence adds value.
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 it is a parameterless tool with an output schema, the description is sufficient. It explains what the tool returns, and the schema covers the rest. No missing details for its simplicity.
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?
There are no parameters (0 params), so baseline 4 applies. The description does not need to add parameter information as the schema is empty.
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 verb 'Get' and the resource 'metadata for all registered MCP tools'. It distinguishes itself from sibling tools that are weather/astronomy related, indicating a separate purpose.
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 or alternatives is provided. The usage is implied as a catalog lookup, but lacks exclusions or context compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses geocoding cascade (Amap → Photon → Nominatim) and weather data aggregation with fallback to open-meteo without API key. Good transparency, but lacks details on rate limits or real-time behavior.
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: starts with purpose, then geocoding details, Chinese tips, and parameter descriptions. Somewhat lengthy but each sentence adds value. Minor redundancy in Chinese text could be trimmed.
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?
Covers key aspects: purpose, geocoding, provider options, and return keys. However, return values are only listed as keys without types or examples; no output schema. Could explain what 'all' provider includes and the structure of _meta. Given complexity, slight 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?
Schema has 0% coverage; description adds full meaning: explains place_name should use full administrative divisions for Chinese, and provider lists valid options (all, qweather, open-meteo, wttr). Adds significant value 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?
Description explicitly states the tool gets comprehensive weather by place name (current + hourly + daily). Distinct from sibling get_weather_by_position by advising use of that tool for precise location. Clear and specific.
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?
Provides clear context on when to use this tool vs get_weather_by_position, and gives tips for Chinese place names (use full administrative divisions). No explicit when-not to use, but alternative is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses caching behavior, the effect of fast mode (skipping OSMnx downloads), and the return structure. It could mention database interactions or rate limits, but the provided information is sufficient for safe usage.
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 (main description, caching note, fast mode, Args, Returns). It is front-loaded with the main purpose. However, the fast mode paragraph contains some repetition (e.g., 'skip road connectivity checks' appears twice), making it slightly less 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 11 parameters, no schema descriptions, and no annotations, the description provides comprehensive coverage: parameter semantics, return format (including keys), caching behavior, and a performance optimization tip. It is fully adequate for an 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?
Schema description coverage is 0%, so the description must fully compensate. The Args section provides clear, detailed explanations for all 11 parameters, including purpose, defaults, and special values (e.g., road_radius_km=0 to skip). This adds significant value beyond the schema's type/default entries.
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 a geographic area for suitable stargazing locations.' It specifies the verb (analyze), resource (geographic area), and domain (stargazing), which distinguishes it from sibling tools that handle celestial data, weather, or planning.
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 includes specific guidance on when to use 'fast mode' (road_radius_km=0) for scenarios without road connectivity needs. However, it lacks explicit comparison to sibling tools or conditions when not to use this tool, though the fast mode advice provides clear context for a common alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool returns a dict with moon_phase, planets, and deep_sky, and that deep_sky is sorted. However, it doesn't mention data freshness or any constraints beyond parameters.
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: a one-line purpose, bullet points for parameters, and clear return format. Every sentence 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 output schema exists and the description explains the return keys, the tool is completely specified. It covers the necessary context for an agent to decide and invoke 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?
The description adds detailed meaning for all 5 parameters, including latitude/longitude, date format, timezone string, and limit default. This far exceeds the input schema which only provides types and default, so it fully 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 it returns a curated list of best objects to view for the night, which distinguishes it from siblings like get_moon_info or list_visible_planets. The verb 'Get' and resource 'curated list' are specific.
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 usage for nightly viewing recommendations by listing relevant parameters (lon, lat, time, time_zone). It doesn't explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-stargazing MCP server](https://glama.ai/mcp/servers/StarGazer1995/mcp-stargazing/badges/card.svg)](https://glama.ai/mcp/servers/StarGazer1995/mcp-stargazing)

Score Badge

Copy to your README.md:

[![mcp-stargazing MCP server](https://glama.ai/mcp/servers/StarGazer1995/mcp-stargazing/badges/score.svg)](https://glama.ai/mcp/servers/StarGazer1995/mcp-stargazing)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/StarGazer1995/mcp-stargazing'

If you have feedback or need assistance with the MCP directory API, please join our Discord server