Skip to main content
Glama
Sign In
Sky Compass MCP

Sky Compass MCP

by cloudyrathor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_supported_objects

Lists built-in celestial objects and accepted SIMBAD-resolvable names so you can choose valid targets for location-based sky compass calculations.

Instructions

List built-in objects; arbitrary SIMBAD-resolvable names can also be requested for location.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_supported_objects"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and no output schema, the description carries the full disclosure burden. It never says what the list actually contains (names, identifiers, coordinates), whether it is static or filtered, or how the SIMBAD-resolvable names relate to the returned set — leaving the agent guessing about the result shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence is appropriately sized, but the semicolon clause about SIMBAD names is front-loaded into the same breath as the core purpose and muddles rather than clarifies. The primary statement should lead cleanly with what is returned.

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?

The tool is simple (no params, no annotations, no output schema), so expectations are low, but the absent output schema means the description should describe what the list looks like. It instead spends its second half on a capability that does not map to any input.

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 takes zero parameters, which is the baseline-4 case. The description confirms nothing is required, though it confusingly implies an optional "request" capability that has no corresponding schema field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb+resource pair "List built-in objects" is identifiable, but "built-in" is never qualified — an agent must infer from the name and siblings that these are celestial objects/places supported by the server. The trailing clause about "arbitrary SIMBAD-resolvable names" is ambiguous in a tool with zero parameters, since nothing can be "requested" here.

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?

There is no explicit when-to-use guidance and no mention of the sibling tools (get_place_coordinates, locate_celestial_object, locate_by_coordinates, track_object). An agent could plausibly infer this is a discovery step before locate_celestial_object, but that routing is never stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools