materials

Find space products

find_products

Read-onlyIdempotent

Search the catalogue of space products (satellites, platforms, structures, launchers, engines, spacesuits, rovers, observatories, stations) by what they are, who makes them, what they are made of and how. Call it first when you design or study a device: "comparable 3U CubeSat structures" = kind structure + size 3U; "who flies aluminium 6061" = material aluminium-6061; "which products use anodised parts per MIL-A-8625" = finish + standard; "launchers by SpaceX" = category launchers + maker. All filters are optional and combine (AND). text matches every word against names, aliases (F9, Orlan, EMU), summaries, specs, features, parts, materials and organizations. Returns, per product, its id (use it with get_product), maker, kind, category, size / mass / orbit tags, a depth label (full, partial or materials-only: how complete its parts list is), counts of parts, materials, specs and unverified quotes, and the page. It does not return the parts: call get_product or product_parts for those. An empty result means no product in this catalogue matches, not that none exists.

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": "find_products"
  }
}

Input Schema

Name	Required	Description
`org`	No	Any organization with a stated role on the product (maker, contractor, supplier, operator), by name or id
`form`	No	Part form to match, for example honeycomb, plate, sheet, tube
`kind`	No	platform, structure, satellite, mission (launchers, vehicles, rovers, suits, observatories) or component
`mass`	No	Mass tag to match, for example "Under 1 kg"
`size`	No	Size tag to match, for example 1U, 3U, "6U and larger", Microsatellite
`text`	No	Words to find, for example "heat shield ablator" or "F9" (aliases work)
`limit`	No	Maximum products, 1 to 100 (default 20)
`maker`	No	Maker name or part of it, for example nasa or "Blue Origin"
`orbit`	No	Orbit tag to match, for example "low earth", geostationary, "sun-synchronous"
`finish`	No	Finish to match, for example anodize, chromate, black paint
`offset`	No	Skip this many (paging)
`category`	No	Catalogue group: platforms, structures, launchers, engines, suits, rovers, crew, stations, observatories, solar, thermal, reports, missions
`material`	No	A material id, for example aluminium-6061 or pi-kapton-hn: products that use it
`standard`	No	Standard to match, for example MIL-A-8625 or AMS
`bom_depth`	No	Only products whose parts list has this depth
`part_function`	No	Part function: structure, thermal control, power, propulsion, mechanisms, avionics, optics, protection or other. DERIVED by explicit name rules from the part names (marked function_basis "derived"), not stated by the sources.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data and the description is judged on what it adds beyond that. The genuine additions are the AND-combination semantics of the optional filters and the important negative-result contract ("An empty result means no product in this catalogue matches, not that none exists").

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 scoping sentence, the call-first directive, and the return-shape summary are front-loaded, and the worked examples are compact and load-bearing rather than decorative. It runs long and slightly duplicates the kind/category vocabularies that already live in the schema, but no sentence is expendable.

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?

For a 16-parameter, zero-required search tool with no output schema, the description carries the missing weight by itemising what each returned record contains (id, maker, kind, category, tags, depth label, counts, page) and by explaining what the `depth` label ('full', 'partial', 'materials-only') actually measures. It also preempts the most likely misuse — expecting parts in the results — and points to the correct siblings.

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?

With 100% schema description coverage the baseline is 3, but the description earns more by explaining that `text` matches every word across names, aliases (F9, Orlan, EMU), summaries, specs, features, parts, materials and organizations — behaviour the schema only hints at with "(aliases work)". It also clarifies that all filters are optional and combined with AND, which resolves how 16 parameters interact.

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?

Opens with a specific verb+resource ("Search the catalogue of space products") and enumerates the resource subtypes it covers (satellites, structures, launchers, engines, rovers, etc.), so the scope is unambiguous. It does not, however, distinguish itself from the sibling `search_products`, which by name appears to overlap almost entirely — that is the one differentiation gap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the primary trigger ("Call it first when you design or study a device") and then maps four concrete natural-language queries onto filter combinations, which is exactly the guidance an agent needs to translate intent into parameters. It also routes the agent away for out-of-scope needs: "It does not return the parts: call get_product or product_parts for those."

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

All materials tools Inspect

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.