Skip to main content
Glama
Sign In

Perigee

by io.github.dlamarre-dev
OverviewDiscussionsAdmin

Link or embed a 3D view

perigee_view
Read-only

Link to Perigee showing an object (optionally at a date, paused or accelerated, followed), and an iframe snippet for a lesson page: the live 3D view without bars or panels. The embedding page can then drive the view and take PNG snapshots with postMessage (protocol perigee:v1, documented in embedApi). For a star, star_map opens its 3D map with the Sun instead (every named star at its real distance, the Sun–star distance drawn; compare adds a second star), alone in the iframe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idYesObject id from perigee_find (NORAD number, mission id, planet, "moon:<id>", "site:<id>", "launch:<id>", "star:<id>", "comet:<id>", "asteroid:<id>" or a dwarf planet name), e.g. "25544" for the ISS.
dateNoISO 8601 UTC instant, e.g. 2026-12-01T00:00:00Z (default: now).
langNoLanguage of names and texts (default en).
rateNoTime multiplier: 1 real time, 0 paused.
panelNoKeep the information panel in the embed.
followNoFollow the object (default true).
compareNoWith star_map: another star (star:<id>) drawn with its distance to compare.
star_mapNoStars only (star:<id>): open the star's 3D map with the Sun, alone in the embed.
time_barNoKeep the time bar in the embed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only carry readOnlyHint and openWorldHint, but the description goes well beyond them: it discloses the embed's appearance (no bars or panels), that the host page can drive the view and capture PNGs via postMessage, and a concrete protocol identifier (perigee:v1) with a pointer to embedApi. That is exactly the kind of post-call capability context an agent needs and cannot get from structured fields.

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?

Two sentences, front-loaded with the purpose, and no filler. The first sentence is heavily parenthetical and slightly run-on, which costs a little readability, but every clause carries actionable information (output type, drive capability, protocol, star branch).

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?

With nine parameters and no output schema, the description usefully compensates by stating what is returned (a link plus an iframe snippet) and how the consumer interacts with it. What is missing is narrower: link shape/format and whether the two outputs are returned together or selectable.

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 coverage is 100%, so the baseline is 3, but the description meaningfully glosses the parameters in prose: 'optionally at a date, paused or accelerated, followed' maps onto date/rate/follow, and it explains the compare/star_map interaction in a way the schema descriptions only state in isolation. It does not, however, explain the apparent tension between 'without bars or panels' and the panel/time_bar flags.

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 first sentence names a specific verb+resource pair: it produces a link and an iframe snippet rendering an object's live 3D view. It clearly describes what the output is, though it never names a sibling tool (e.g. perigee_describe_view) as the alternative for non-embedding use cases, so a reader must infer the boundary with the rest of the family.

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 intended context is explicit ('for a lesson page', 'the embedding page can then drive the view'), and it gives a real conditional branch: 'For a star, star_map opens its 3D map with the Sun instead.' It stops short of saying when not to use this tool or naming a sibling alternative, so it lands at clear-context-without-exclusions.

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

All Perigee toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources