Skip to main content
Glama
Sign In

materials

by com.spacemushroom
OverviewDiscussionsAdmin

Get a space product

get_product
Read-onlyIdempotent

The whole record of one product: specs, features, the parts tree (assemblies, parts, material, form, finish, standard, part number, supplier, function), the materials it uses (ids that work with get_material), standards, the organizations behind it (maker, contractors, suppliers, operators), relations to other products (engine part of vehicle, launched on, heritage), photos with credits, and what_is_missing. Call it to study a device: "what is Perseverance's heat shield made of and what heritage does it have", "what is Starship made of and what is not published". Accepts an id, a title or an alias (F9, Orlan, EMU, Webb). Every row has its source URL, its quote and quote_status. what_is_missing is computed: the depth label (full, partial, materials-only), what the sources do not publish, parts without a material, parts without a source, materials with no page yet, relations to names that are not products here, and the count of unverified quotes. The answer can be long for big vehicles: use sections to ask only for what you need, and part_function to cut the parts.

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": {
      "product": "<product>"
    },
    "name": "get_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
productYesProduct id, title or alias, for example nasa-perseverance-rover, Starship or F9
sectionsNoOnly these sections (default: all). summary, depth and what_is_missing are always included
part_functionNoOnly parts with this function (the parts section)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already carry readOnly, idempotent, non-destructive and closed-world hints, so the description is free to spend itself on real behavior: every row carries source URL, quote and quote_status, and the result can be very long for large vehicles with sections/part_function as the mitigation. That is meaningful context beyond the annotation block; it just lacks failure behavior for an unresolvable id/alias.

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?

Front-loaded with the payload summary, then usage examples, then the size-mitigation advice — a sensible order with little waste. The parenthetical enumeration of parts-tree fields is dense and long, but each item informs what the agent will receive, so it earns most of its space.

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?

With no output schema, the description carries the full return-shape burden and does so: it lists every section, explains the computed what_is_missing breakdown, states the per-row provenance fields, and warns about response length with concrete knobs to shrink it. An agent could call this correctly with no further information.

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 adds meaning the schema does not: that `product` accepts aliases in practice (F9, Orlan, EMU, Webb) and that what_is_missing is computed rather than omitted. It restates some schema content (sections, part_function trimming) but the alias and computed-field detail are genuine additions.

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?

Names a specific verb and resource ("the whole record of one product") and enumerates the exact payload: specs, features, parts tree, materials, standards, organizations, relations, photos, what_is_missing. It distinguishes itself from siblings by noting the material ids "work with get_material" and that what_is_missing is an always-computed block rather than a separate call.

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?

Gives explicit trigger conditions via worked example questions ("what is Perseverance's heat shield made of", "what is Starship made of and what is not published") and tells the agent to narrow output with sections/part_function for big vehicles. It stops short of naming when NOT to use it — e.g. deferring to product_parts or product_graph for pure graph traversal.

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

All materials 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