Find craters, mountains and landing sites on the Moon, Mars and more to 3D print in OrbitStudio.
Scored across 6 tools
Each tool targets a distinct resource and action: browsing published images (get_preview), product/pricing facts (get_product_info), the world catalogue (list_worlds), place lookup (search_places), Earth star-map links (star_map_link), and print-setting suggestions (suggest_model). Even the two place-oriented tools split cleanly by output — pictures versus settings plus a generator link.
Five of six names follow a clear verb_noun pattern (get_preview, get_product_info, list_worlds, search_places, suggest_model). star_map_link breaks the pattern as a noun compound, but it is readable and self-evident.
Six tools is a tight, well-scoped set for a product-discovery/link-generation server; each tool covers a distinct user intent with no filler. Nothing feels thin or padded.
The surface covers the core journey: learn the product, list worlds, find a place, preview results, and get settings plus a generator link, with star maps as a parallel path. Minor gaps exist — no way to fetch detailed per-place metadata such as elevation ranges or to retrieve a finished model link — but these are workable around via the generated links.
Return pictures already published on orbitstudio3d.com for a world or a place: photos of printed models, renders made with the app, and the world's map texture, each captioned with what it shows. Use it when the user wants to see what a model looks like. Nothing is rendered on request.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Optional place name or id from search_places. | |
| world | Yes | Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the description is free to add value elsewhere — and it does, clarifying that nothing is generated on demand and that results are pre-published assets with captions. Returned content types are described, though nothing is said about volume, pagination, or what happens for a world with no pictures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and content inventory, followed by the usage cue. The middle clause is a slightly dense list but every element carries information; nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, full schema coverage, and rich annotations, the description supplies what structured data cannot: what the pictures are, that they are captioned, and that no rendering occurs. Only edge-case behavior (empty results, unsupported world) is left unstated, which is tolerable for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the world enum is spelled out in the schema itself, so the description only echoes 'for a world or a place' without adding format or selection guidance. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return pictures already published on orbitstudio3d.com'), enumerated content types (printed-model photos, app renders, map texture), and explicitly disambiguates from the misleading name by saying 'Nothing is rendered on request.' An agent cannot confuse this with a rendering or model-suggestion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('Use it when the user wants to see what a model looks like') plus an explicit exclusion ('Nothing is rendered on request'). No sibling is named as an alternative, but none of the listed siblings (list_worlds, search_places, suggest_model) is a plausible substitute, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Facts about OrbitStudio: what it makes, its two tools and the worlds offered, which steps are free and which are not, a link to the page that lists the plans, and the support address. Use it when the user asks what OrbitStudio is or which parts of it are free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond the annotations by enumerating what is actually returned, which partially substitutes for the absent output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the topic ('Facts about OrbitStudio') followed by the content list and then the usage trigger. The content enumeration is dense but each item maps to something the agent may need to answer a question; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so by listing the topics covered. Combined with annotations covering the safety profile, an agent has what it needs, though it lacks any note on response format or freshness of the pricing/plan information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline this scores 4. There is nothing for the description to clarify beyond the fact that no input is required, which is implied by its informational framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (OrbitStudio) and enumerates the specific content returned: what it makes, its two tools and worlds, free vs. paid steps, the plans link, and the support address. That is enough to distinguish it from siblings like list_worlds or suggest_model, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Use it when the user asks what OrbitStudio is or which parts of it are free.' That is clear when-to-use guidance, but there is no when-not guidance and no named alternative for adjacent questions (e.g., about worlds or previews), which the sibling list makes relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the worlds OrbitStudio currently offers, with each world's size, number of known places, default relief, smallest selection and data caveats. Use it when the user asks which planets or moons can be printed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so safety is covered. The description goes beyond that by disclosing the returned content, including 'data caveats', which is useful operational context an agent would not infer from the annotations. It does not cover pagination or response shape, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The returned-field list is front-loaded in sentence one and the usage trigger in sentence two, so both an invocation decision and a selection decision are supported immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description carries the burden of describing returns, and it does so by naming the exact per-world fields including the caveat field. For a parameterless, read-only listing tool this is sufficient for an agent to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4: there is no parameter semantics for the description to add, and the description correctly implies a no-argument call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (list) plus a concrete resource (worlds currently offered) and an enumeration of the fields returned: size, known places count, default relief, smallest selection, data caveats. That field set is unique among its siblings, so an agent can tell list_worlds apart from get_preview, get_product_info, or search_places without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives an explicit trigger: 'Use it when the user asks which planets or moons can be printed.' That is a clear usage context, but it names no exclusion or explicit alternative tool for adjacent requests (e.g. when the agent should call search_places or get_product_info instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the named places OrbitStudio can open directly: craters, mountains, valleys, basins and spacecraft landing sites on the Moon and other worlds. Use it when the user names or describes a place to 3D print, or asks what there is on a world. Returns each match's world, coordinates, the size of its box in the app's travel list, a short description and a link that opens the generator at that place.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most results to return. | |
| query | Yes | Name or part of a name, e.g. 'Tycho', 'Apollo 11', 'Olympus', 'volcano'. | |
| world | No | Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explaining that it searches only places OrbitStudio can open directly and by describing each result's fields and the generator-opening link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's purpose, followed by when to use it and what it returns. Every sentence contributes useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by naming the returned fields: world, coordinates, box size, short description and generator link. With annotations covering safety and schema covering parameters, the definition is complete for this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so query, world and limit are already documented in the schema. The description does not add syntax or format details beyond those schema descriptions, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('named places OrbitStudio can open directly'), then enumerates the place types. It distinguishes this from sibling tools like list_worlds by focusing on named places rather than worlds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: 'Use it when the user names or describes a place to 3D print, or asks what there is on a world.' It does not explicitly state when not to use it or name an alternative sibling, but the scenario is specific enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a link that opens OrbitStudio Sky with the night sky over a place on Earth at a local date and time, as a 3D-printable star map plate. Use it for a birth, wedding or 'night we met' star map. Give a place name, which is looked up on OpenStreetMap, or latitude and longitude, which win when both are given. When a name matches more than one place, the tool lists them instead of choosing: ask the user which one they mean.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Local date, YYYY-MM-DD, 1900-01-01 to 2100-12-31. | |
| time | No | Local time, HH:MM 24-hour. Defaults to 21:00. | 21:00 |
| label | No | Optional text engraved on the plate instead of the place name. | |
| place | No | The place on Earth, e.g. 'Amsterdam, Netherlands'; adding the region or country avoids a list of candidates. Looked up when latitude and longitude are not given. Also the label engraved on the plate (first 40 characters) unless label is given. | |
| latitude | No | Latitude in degrees. Give it with longitude instead of a place name; it wins over one. | |
| longitude | No | Longitude in degrees east (negative is west). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive) and open-world access, so the description is not carrying that burden. It still adds real behavior: the OpenStreetMap lookup dependency, lat/long winning over place, and the crucial ambiguity case where the tool returns candidates instead of picking one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the outcome, then inputs, then edge-case handling. Every sentence carries information an agent needs; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states that the return is a link and that ambiguous matches yield a list of candidates instead of a link. That covers the main return-value ambiguity for this tool, though it leaves minor details (exact link format, whether errors are surfaced) unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema, including the precedence of latitude/longitude and the place-as-label fallback. The description restates that precedence but adds no format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it builds a link that opens OrbitStudio Sky showing the night sky over a place at a local date/time as a 3D-printable star map plate. That is concrete enough to separate it from siblings like search_places or get_preview without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases (birth, wedding, 'night we met') and the precedence rule for place vs. latitude/longitude. It also prescribes behavior for ambiguous place names (list them, ask the user), which is effectively when-to-do-what guidance. It stops short of naming an alternative tool for resolving ambiguous places.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest OrbitStudio settings for a 3D-printed puzzle or ornament of a place, from the app's own defaults and the limits of that world's elevation data, plus a link that opens the app at the place with those settings filled in, ready for the user to press Generate. Use it when the user wants to make or print a model of a specific place. Give either a place from search_places or latitude and longitude (a coordinate link cannot carry settings). Shape, size and relief may be chosen; otherwise the app's defaults apply.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place name or id from search_places, e.g. 'tycho'. | |
| shape | No | Outline of the model. | circle |
| world | Yes | Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted). | |
| relief | No | Terrain Height Scale; 1 is true scale. Defaults to the world's own starting value. | |
| purpose | No | puzzle for a jigsaw puzzle; ornament, gift or display for a solid model. | ornament |
| size_mm | No | Printed width or diameter in mm (rounded to 10); fit it to the printer's bed. | |
| latitude | No | Latitude in degrees, if no place is given. | |
| longitude | No | Longitude in degrees east, if no place is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description is not needed for the safety profile. It still adds real value by disclosing what the tool actually produces: a link that opens the app ready for the user to press Generate, meaning nothing is generated server-side. The defaults-fill behavior for shape, size and relief is also stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the outcome (settings plus a ready-to-generate link) before the usage condition and input options. Sentences carry distinct information with little repetition, though the closing defaults sentence partly restates schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description fills the gap by describing the returned artifact (a deep link with settings filled in) rather than raw data. Input modes, defaults, and the required world context are all covered, leaving nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantics beyond the schema: place comes from search_places, coordinates are an alternative input mode that loses the settings payload, and shape/size/relief are optional with app defaults substituting. That coordinate-link caveat is not obvious from the parameter definitions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (suggest) and resource (OrbitStudio model settings for a 3D-printed puzzle or ornament of a place), plus the concrete deliverable: a link that opens the app with settings prefilled. An agent can distinguish this from search_places (a data source it names) and from the other siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when the user wants to make or print a model of a specific place" gives a clear trigger, and it names search_places as the prerequisite for place input. It also warns that a coordinate link cannot carry settings, which steers the agent toward named places. It stops short of explicitly excluding sibling tools such as get_preview or star_map_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_preview1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted)."search_places1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted)."suggest_model1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, jupiter, pluto, vesta, ceres, mimas, enceladus, tethys or charon (only the ones OrbitStudio currently offers are accepted)."star_map_link5 fields changedInput schema / properties / labelAdded value: +{
+ "description": "Optional text engraved on the plate instead of the place name.",
+ "maxLength": 40,
+ "type": "string"
+}Input schema / properties / latitude / descriptionPrevious value: -"Latitude in degrees."New value: +"Latitude in degrees. Give it with longitude instead of a place name; it wins over one."Input schema / properties / place / descriptionPrevious value: -"Optional label engraved on the plate, e.g. 'Amsterdam, Netherlands'."New value: +"The place on Earth, e.g. 'Amsterdam, Netherlands'; adding the region or country avoids a list of candidates. Looked up when latitude and longitude are not given. Also the label engraved on the plate (first 40 characters) unless label is given."Input schema / properties / place / maxLengthPrevious value: -40New value: +120Input schema / requiredPrevious value: -[
- "latitude",
- "longitude",
- "date"
-]New value: +[
+ "date"
+]get_preview1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."search_places1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."suggest_model1 field changedInput schema / properties / world / descriptionPrevious value: -"Which world: moon, mars, mercury, venus, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."New value: +"Which world: moon, mars, mercury, venus, vesta, ceres, pluto or charon (only the ones OrbitStudio currently offers are accepted)."get_previewget_product_infolist_worldssearch_placesstar_map_linksuggest_modelPositions, distances, mission facts and 3D views of objects orbiting the Earth, Moon, Mars and Sun.
3D printing: printable models, calculators, troubleshooting wiki, build guides, AI 3D + CAD design.
Design 3D-printable multi-colour map models from OpenStreetMap data, render them, and share them.
Find recent or archived satellite imagery for any place on Earth by location and date.
Add one secure layer between your agents and this server.