Skip to main content
Glama
Sign In

materials

by com.spacemushroom
OverviewDiscussionsAdmin

Standards used by products

standards_for
Read-onlyIdempotent

The specifications named by products: standards listed for a product (with what they are used for) and the standard written on each part (anodising, chromate, welding, composites ...), each with the part function, the quote and the source where there is one. Give a product ("which standards does the Pumpkin CubeSat Kit structure cite"), a part function ("which standards are used on structural parts"), or both. The function tag is derived from the wording; the standard names are as the sources print them. An empty answer means none named in the sources read.

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

Input Schema

NameRequiredDescriptionDefault
productNoProduct id, title or alias
part_functionNoPart 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.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the derivation caveat (function tag is derived by name rules, not stated by sources), the verbatim-source caveat on standard names, and the explicit meaning of an empty result. These are real behavioral disclosures an agent could not infer from the annotations.

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?

The first sentence is a long, parenthetical-laden run-on that is hard to parse before the reader reaches the useful query examples. The usage examples and empty-result note earn their place, but the opening could be split and tightened noticeably.

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 no output schema and only two optional parameters, the description does the necessary work by enumerating the fields returned (use, part function, quote, source) and warning that absences are relative to the sources read. It is close to complete for a read-only lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. The description adds the combinability semantics (either parameter alone or both together) and repeats the derived-function and verbatim-name caveats that the schema already states, so it contributes only modest meaning beyond the structured fields.

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 description names a specific resource (standards/specifications cited by products and parts) and what is returned (standard, what it is used for, part function, quote, source), which distinguishes it from siblings like find_materials or product_parts. The opening clause is dense and reads awkwardly, but the concrete product example makes the intent unambiguous.

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?

It explicitly states the accepted query shapes — a product ("which standards does the Pumpkin CubeSat Kit structure cite"), a part function ("which standards are used on structural parts"), or both — which tells an agent how to drive the tool. It does not name an alternative sibling or state when not to use it, so it falls short of full routing guidance.

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